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
