[GRASS-git] [OSGeo/grass] 2b85ab: lib: Increase max size of SQL statements (#1124)

Vaclav Petras noreply at github.com
Mon Jul 25 08:37:48 PDT 2022


  Branch: refs/heads/main
  Home:   https://github.com/OSGeo/grass
  Commit: 2b85ab5eb4c58d1213386f59d125a0729ad91870
      https://github.com/OSGeo/grass/commit/2b85ab5eb4c58d1213386f59d125a0729ad91870
  Author: Vaclav Petras <wenzeslaus at gmail.com>
  Date:   2022-07-25 (Mon, 25 Jul 2022)

  Changed paths:
    M include/grass/dbmi.h

  Log Message:
  -----------
  lib: Increase max size of SQL statements (#1124)

Increases length of SQL statements in db.execute and elsewhere (DB_SQL_MAX)
from 1024 * pow(2, 3) to 1024 * pow(2, 6). Longer SQL statements are needed
for long attribute values, but also for tables with a lot of columns,
esp. when this table needs to be dropped and re-created during v.db.dropcolumn
(which is the original motivation for this change).

The new value is much higher than the current one and the SQL statement I had problem with in the v.db.dropcolumn case above. However, since this is likely to be bigger than a path or other things we have fixed sizes for, it seems it deserves more.

One char array would now take 0.0625 MiB which may be a problem if rest of the program allocates a lot of other things on stack, but likely fine because there is usually only few instances DB_SQL_MAX array in the program. If every occurrence of DB_SQL_MAX in the code (77) would be allocated at the same time (which is not the case), it would be under 5 MiB which still fits into glibc stack size (7.4 MB).

The stack size issue may appear on some special platforms where 65536 bytes is a significant part of the stack size limit, but in general, for these platforms even 16384 can be too much since 65536 bytes might be the whole stack size or more on some systems (HP-UX 11 has 16 KB). This makes even our current value of 8192 bytes barely acceptable there, so increasing it is probably not an issue because the code doesn't work there already.

A real, ideal fix would be having no limit and using dynamically allocated arrays for all SQL statements.




More information about the grass-commit mailing list