Date: Wed, 25 Mar 2026 19:54:42 +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: <acQ9gnE84897xHfQ@ip-10-97-1-34.eu-west-3.compute.internal>
References: <abpfH33mR4Mp9dtO@paquier.xyz>
 <abq71eL7qIdWAxMD@ip-10-97-1-34.eu-west-3.compute.internal>
 <abufUya2oK-_PJ3E@paquier.xyz>
 <abvrRZo52Yx9ZzWQ@ip-10-97-1-34.eu-west-3.compute.internal>
 <ab4y1UQUsSS7bSVd@paquier.xyz>
 <acI3H5aucJNS2w78@paquier.xyz>
 <hlkdrplgrmudbspibsuq6xooxrqxqsgwo6x5b6x5ptvkgjbe7w@xogt6xgua6dz>
 <acMiT69EEGKHWGM5@paquier.xyz>
 <acNTR1lLHwQJ0o+P@ip-10-97-1-34.eu-west-3.compute.internal>
 <acNxrWn2bvDARnC3@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="AUNYTZhlO/wpj51V"
Content-Disposition: inline
In-Reply-To: <acNxrWn2bvDARnC3@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/acQ9gnE84897xHfQ%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk


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

Hi,

On Wed, Mar 25, 2026 at 02:25:01PM +0900, Michael Paquier wrote:
> On Wed, Mar 25, 2026 at 03:15:19AM +0000, Bertrand Drouvot wrote:
> > Thanks for the test removal. I created an open item for v19 so that we
> > don't forget to re-add a new version of the tests. I'll work on it.
> > 
> > [1]: https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
> 
> Thanks for adding that.  We are most likely going to need the help of
> the CI here.  The buildfarm has been fortunately (unfortunately?)
> stable on this one, and that would make for less noise overall.

PFA a new version of the tests using an injection point. This new injection
point is created in ProcSleep() when we know that the deadlock timeout fired.

The patch adds a new query_until_stderr() subroutine in BackgroundPsql.pm:
It does the same as query_until() except that it is waiting for a desired
stderr (and not stdout). Thanks to it the session can wait until it gets the
injection point notice.

I think that looks clearer that way than using the logfile to look for the
notice (should log_min_messages be set to an appropriate value).

If you like the idea, maybe we could introduce query_until_stderr() in a separate
commit. If you don't, then we could switch to looking in the server logfile
instead of the session stderr.

Then the new tests follow this workflow:

- session 1 holds a lock
- session 2 attaches to the new injection point with the notice action
- session 2 is blocked by session 1 and waits until the injection point notice
  is received
- session 1 releases its lock, session 2 commits
- pg_stat_lock is polled until we get the counters for the lock type or die
with a timeout

That way there is no sleep at all. Once we know that session 2 has waited longer
than the deadlock timeout (thanks to the new injection point notice) then we
can release the locks and poll pg_stat_lock to get the updated stats.

Regards,

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

--AUNYTZhlO/wpj51V
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v1-0001-Add-new-tests-for-lock-stats.patch"