Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter@eisentraut.org>, Jakub Wartak <jakub.wartak@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2023-09-27T22:53:45Z
Lists: pgsql-hackers
On Wed, Sep 27, 2023 at 10:29:25AM -0700, Andres Freund wrote: > I don't think going for size_t is a viable path for fixing this. I'm pretty > sure the initial patch would trigger a type mismatch from guc_tables.c - we > don't have infrastructure for size_t GUCs. Nothing marked as PGDLLIMPORT uses size_t in the tree currently, FWIW. > Perhaps we ought to error out (in BackendStatusShmemSize() or such) if > pgstat_track_activity_query_size * MaxBackends >= 4GB? Yeah, agreed that putting a check like that could catch errors more quickly. > Frankly, it seems like a quite bad idea to have such a high limit for > pgstat_track_activity_query_size. The overhead such a high value has will > surprise people... Still it could have some value for some users with large analytical queries where the syslogger is not going to be a bottleneck? It seems too late to me to change that, but perhaps the docs could be improved to tell that using a too high value can have performance consequences, while mentioning the maximum value. -- Michael
Commits
-
Avoid memory size overflow when allocating backend activity buffer
- 9b3900cdb734 12.17 landed
- a0b013625908 13.13 landed
- f91c87b31463 14.10 landed
- 95e91da66cf5 15.5 landed
- 75f31a3f2674 16.1 landed
- a956bd3fa9d9 17.0 landed