Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 28 Sep 2023 07:53:45 +0900
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>
Subject: Re: pg_stat_get_activity(): integer overflow due to (int) * (int)
 for MemoryContextAllocHuge()
Message-ID: <ZRSyefTyBOJi3Ydu@paquier.xyz>
References: <CAKZiRmw8QSNVw2qNK-dznsatQqz+9DkCquxP0GHbbv1jMkGHMA@mail.gmail.com>
 <ZRPi9xOBFoTJ5rTb@paquier.xyz>
 <45ba068b-66ea-b74c-5a92-6c2127d63e28@eisentraut.org>
 <20230927172925.xmyoardgxoifdpgu@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="WNUdom0xhFYe0o5M"
Content-Disposition: inline
In-Reply-To: <20230927172925.xmyoardgxoifdpgu@alap3.anarazel.de>
Archived-At: <https://www.postgresql.org/message-id/ZRSyefTyBOJi3Ydu%40paquier.xyz>
Precedence: bulk


--WNUdom0xhFYe0o5M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--WNUdom0xhFYe0o5M
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmUUsnkACgkQnvQgOdby
QH1KsRAAmvKP0oUPVtKuhnWO9N3whHn+3DX7SYXV1wCtAGWFi1s+M45FYZ1HfgFS
roANu0YcZN+kKRFw92cU+CkhKlvI0k7ZCqeDNeQylr/mISfi52dlbiYPjfo4rNEn
OjoWPAefVf6rnzFb3/j680+b7CwYk5OMI4U/VTrHlbVuFNEAf4tJg6TtNeSD99ck
CGIrMtkBzUcdVXa5QSde5Gc7/PmPfUVDukDn2NbAAAVP5tRyGv53XfCNJY0QDkRS
gVPYeLh9M/7eldD8LcOvTLqceZlbMyiU+40d8KnQUHXrPGkZgH4T+0J0QxgDBf4w
10S492L95RikmDHORgkaeoTsUVLDgGZvEJOr5WNmDPUEoNcBhhOBuII4Zu+DIv5j
Azp5BS8ucFmf3UG70vNTDvFqtPHI7tOO3AS6rFTuvzmItFxM14O4etNEBm1VYE9R
Wjo2EkKhQ0j6qcoU8LzhrquHfS1xW7E+dEmArhSi9SnfMw3dwlpZrVSZY8QU0KKL
ceVX6hgfFeyM5CxQsKJ2KNm+dizfKVflFW7H9BGViZxnvJ/ejWp+ShebhqxOn4fP
+fNmzr6n9u+JwFiPHy1XhBctnsp8WimsDDz849rMyS0683duVOPtSxEDE3uQjMCU
5herMYiYuAMrLed+S6OfzqPV6Tl9Fcw5ZX3yT40oZVsGQmxm4L8=
=nFWw
-----END PGP SIGNATURE-----

--WNUdom0xhFYe0o5M--