Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Michael Paquier <michael@paquier.xyz>, Jakub Wartak <jakub.wartak@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2023-09-27T17:29:25Z
Lists: pgsql-hackers
Hi, On 2023-09-27 15:42:15 +0100, Peter Eisentraut wrote: > On 27.09.23 09:08, Michael Paquier wrote: > > On Wed, Sep 27, 2023 at 08:41:55AM +0200, Jakub Wartak wrote: > > > Attached patch adjusts pgstat_track_activity_query_size to be of > > > size_t from int and fixes the issue. > > > > This cannot be backpatched, and using size_t is not really needed as > > track_activity_query_size is capped at 1MB. Why don't you just tweak > > the calculation done in pgstat_read_current_status() instead, say with > > a cast? > > I think it's preferable to use the right type to begin with, rather than > fixing it up afterwards with casts. 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. Nor do I think either of the patches here is a complete fix - there will still be overflows on 32bit systems. Perhaps we ought to error out (in BackendStatusShmemSize() or such) if pgstat_track_activity_query_size * MaxBackends >= 4GB? 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... Greetings, Andres Freund
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