Date: Wed, 18 Mar 2026 14:51:01 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
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: <abq71eL7qIdWAxMD@ip-10-97-1-34.eu-west-3.compute.internal>
References: <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>
 <abpfH33mR4Mp9dtO@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="NJ5Y8xm2S5PE3Q71"
Content-Disposition: inline
In-Reply-To: <abpfH33mR4Mp9dtO@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/abq71eL7qIdWAxMD%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk


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

Hi,

On Wed, Mar 18, 2026 at 05:15:27PM +0900, Michael Paquier wrote:
> 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, 0003 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 extra complexity
> >> (I don't have a strong opinion on it but tempted to think that the extra GUC is
> >> not worth it).
> > 
> > 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.

Thanks for looking at it!

> 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.

Yeah, added a few words in the callers and on top of the function definitions.

> 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.

Yeah, that was also my vote.

> 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?

This is done that way in the attached, so that we don't need the extra output 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)).

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

--NJ5Y8xm2S5PE3Q71
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v10-0001-Add-lock-statistics.patch"