Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 18 Mar 2026 17:15:27 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Jeff Davis <pgsql@j-davis.com>,
	Greg Sabino Mullane <htamfids@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Adding locks statistics
Message-ID: <abpfH33mR4Mp9dtO@paquier.xyz>
References: <aZLtDbGEqSN2MuRb@ip-10-97-1-34.eu-west-3.compute.internal>
 <otjn7ykaezlueayyp7fppggkldw23ykh3i6ite2rqq4xh7dwvl@w5dvqqgvqf25>
 <aZSYcsRmqh7grqJb@ip-10-97-1-34.eu-west-3.compute.internal>
 <aZaMXK90sRjSQBJP@paquier.xyz>
 <v76tz252usppu2turrn6wxiyyxmybzxhqck5b3amtsbzrc6yto@n26qnwvpkxqw>
 <aZgBTyzxWmPJL0Tt@ip-10-97-1-34.eu-west-3.compute.internal>
 <isi5wszczhusgjetxwe6khxa5mbm5jms3msmbhwl73jktxw7ic@3mympoumua76>
 <aZiZTX1l5pX+BOXn@ip-10-97-1-34.eu-west-3.compute.internal>
 <aaEoN1XexvGiFvYp@ip-10-97-1-34.eu-west-3.compute.internal>
 <abortN3ngqMcaBJ7@ip-10-97-1-34.eu-west-3.compute.internal>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="FyHEoOC59dxN3D2E"
Content-Disposition: inline
In-Reply-To: <abortN3ngqMcaBJ7@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: 
 <https://www.postgresql.org/message-id/abpfH33mR4Mp9dtO%40paquier.xyz>
Precedence: bulk


--FyHEoOC59dxN3D2E
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 18, 2026 at 04:36:04AM +0000, Bertrand Drouvot wrote:
>> So, we're back to what we were discussing before the split. As in v7, 00=
03 is
>> adding the new GUC. So that we can see what having a new GUC implies in =
ProcSleep()
>> and we can just get rid of 0003 if we think the GUC is not worth the ext=
ra complexity
>> (I don't have a strong opinion on it but tempted to think that the extra=
 GUC is
>> not worth it).
>=20
> PFA, a rebase due to fd6ecbfa75ff.

Looking again at this patch, all the fields that you are adding are in
non-critical paths, so it looks fine by me to begin with this data
set.  We may want to document that for future readers of the code to
not add counter increments in the fast code paths, where performance
could matter.

Let's also drop 0003 with the GUC.  log_lock_waits is enabled by
default and we are in a wait path which would not be
performance-critical.

Regarding the isolation test, the new permutations add 4 pg_sleep()
calls at 500ms each, making the stats test longer.  It also looks like
the outputs are the same for the two alternate expected files?  Do you
think that it could be possible to move these tests to a new file,
perhaps cutting a bit the sleeps to make it faster?
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmm6Xx8ACgkQnvQgOdby
QH1QUw/+M/fmc02OLu+uPEB8sKkaNWNF8vhaKRhtEnLFfFVw3zDvVi/xjdFjAh07
DLmnKxdWo/n8GbXm1LtbypG3X437CgKR+XqR/QB40JR/BdFffCFzdAWnkT+XB/Cz
PTId+o3/O7nFAlP2YnadPzcN8vcVM3jzaP335VY7+skJB1RyzSh88euH+efonu0B
Ef93uj1bX7QbvqLt92OZqjijzJPokc9T90EiEwMG+Qp0jJbIp7KfYXX9UU3tNers
66XE3AVJ7i4reAz4Ua0boyVWEACmPAOVaDxjyXuJUCAKPBkxQQBm97W5H5V4a/p9
PQjAjuaNR98Ms2qStJaI7mp4V9jsy/A0mxT7vKIWK9c4pUjOAO/YezCbkzYRw/gc
rnQhZXxKZUOltrBjCgCZ4tBS8h3p8pU08VRwspT7dmymOjEpZiLdpiVCUa6Z5AoQ
yIYpKLjIbyON5RAxZjHQeO4VEgdArJqxTbNmCmXOlOsnVEkJ9N5/ntzChzUImorD
9vCnESkCpPOvE372gvF92kaQ6o8dQw9M8QGF2YsBqDkdSLJpXMWUAuyjiFxmnpBG
73/w/JzasYJSx/f+ck04DEzuJhx0+eHQecsu2MRkuG73Bt6jCXZF3hK8MEEBe1KJ
tNua2CnIzMz6mqgVQituytWkDHyK1SjgdTQmWeis3G2wINlowp4=
=FTuu
-----END PGP SIGNATURE-----

--FyHEoOC59dxN3D2E--