Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 19 Mar 2026 16:01:39 +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: <abufUya2oK-_PJ3E@paquier.xyz>
References: <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>
 <abpfH33mR4Mp9dtO@paquier.xyz>
 <abq71eL7qIdWAxMD@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="aklLOoCAuKvq8w1F"
Content-Disposition: inline
In-Reply-To: <abq71eL7qIdWAxMD@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: 
 <https://www.postgresql.org/message-id/abufUya2oK-_PJ3E%40paquier.xyz>
Precedence: bulk


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

On Wed, Mar 18, 2026 at 02:51:01PM +0000, Bertrand Drouvot wrote:
> This is done that way in the attached, so that we don't need the extra ou=
tput in
> the _1.out file and the test time is reduced (since the deadlock timeout =
is set
> to 10ms in the test, I changed the sleep time to 50ms (I did not want to =
be very
> close to 10ms)).

> +        <structfield>waits</structfield> <type>bigint</type>
> +       </para>
> +       <para>
> +        Number of times a lock of this type had to wait because of a
> +        conflicting lock. Only incremented when <xref linkend=3D"guc-log=
-lock-waits"/>
> +        is enabled and the lock was successfully acquired after waiting =
longer
> +        than <xref linkend=3D"guc-deadlock-timeout"/>.
> +       </para>
> +      </entry>

It does not make much sense to me to decide that the counter is
incremented if a GUC related to a control of the logs generated is
enabled.  It's a fact that log_lock_waits is enabled by default these
days, hence we will be able to get the time calculation for free for
most deployments, but it seems inconsistent to me to not count this
information if the GUC is disabled.  We should increment the counter
and aggregate the time spent on the wait all the time, no?

+ * Copyright (c) 2021-2025, PostgreSQL Global Development Group=20

Incorrect date at the top of pgstat_lock.c.

storage/lock.h is included in pgstat.h as LOCKTAG_LAST_TYPE is wanted
for the new lock stats structure.  That would pull in a lot of header
data into pgstat.h.  How about creating a new header that splits a
portion of lock.h into a new file?  LockTagType, LOCKTAG_LAST_TYPE,
LockTagTypeNames at least and perhaps a few other things?  Or we could
just limit ourselves to a locktag.h with these three, then include the
new locktag.h in pgstat.h.

It would be nice to document at the top of the new spec file what this
test is here for, and perhaps name it stats-lock instead?
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmm7n1MACgkQnvQgOdby
QH3DuQ/9ENxOuJZLmFj7p+GR1M/7h3I3jM3oINYgjJwMpxxBX1UpHPBIZVCQaswx
TppscT1wuMTXXAnOnKnoUmj9hlP/J9ixIqZb5a1CuWal6FGH3sObmhCfLrcrqZAP
tE+lmECPzAR4QqGVdD10QhnT5VYWQE3Fyc0EmJG/z7f3Tr8GjyhKbpcosTRYguwJ
C4NrojqZ/N2vDOricvfUxw/sS3APrEkpolHMDAiOAIfggRlz4S7nXzMEPZErJH8X
p/FsWkAtE7XM5ADZQDwsc5AEye/jyf/cou9wLqFAIj/tPfV4+PfCJg2E8O2fxe2+
0OWOmf/BcpzqBVbNflG6Uy+FDEPRrN7d0ntOHQ4kaF1yLb4m36VH0MBZDqUxCbs1
K8VgNyhPJpLulewIPvhsBJ2teE9QW9ochg9D8objwDdfpZwcltgQi6APd7KklD+N
VUx+/cTYHKIZMvKnijupoCUZs1ms3aPhdRdApYWAXkySMQvXu6xgqPb2X7zWqcmO
3wup5UuAGLHNo6+AdqxnbEh5H55UDiMd7HCIB18QotYG29AluoOm0okz9CbNp0lg
3Ba2v+f2PlKzdlLimV9VvvJdxnYt40p1NByXzBFZfFuhO9nDNrnESFQOwWuA7i4u
by9l+2TF5QYCHnLuxFwmYI6l11OlQNfN7A8+sMJqg45T95G6O+c=
=2MMo
-----END PGP SIGNATURE-----

--aklLOoCAuKvq8w1F--