Feedback-ID: id4a34324:Fastmail
Date: Wed, 27 Sep 2023 10:29:25 -0700
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>
Subject: Re: pg_stat_get_activity(): integer overflow due to (int) * (int)
 for MemoryContextAllocHuge()
Message-ID: <20230927172925.xmyoardgxoifdpgu@alap3.anarazel.de>
References: <CAKZiRmw8QSNVw2qNK-dznsatQqz+9DkCquxP0GHbbv1jMkGHMA@mail.gmail.com>
 <ZRPi9xOBFoTJ5rTb@paquier.xyz>
 <45ba068b-66ea-b74c-5a92-6c2127d63e28@eisentraut.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45ba068b-66ea-b74c-5a92-6c2127d63e28@eisentraut.org>
Archived-At: <https://www.postgresql.org/message-id/20230927172925.xmyoardgxoifdpgu%40alap3.anarazel.de>
Precedence: bulk

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