Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()
От | Andres Freund |
---|---|
Тема | Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge() |
Дата | |
Msg-id | 20230927172925.xmyoardgxoifdpgu@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge() (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: pg_stat_get_activity(): integer overflow due to (int) * (int) for MemoryContextAllocHuge()
|
Список | 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
В списке pgsql-hackers по дате отправления: