Re: Adding locks statistics
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
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
Date: 2026-03-25T19:54:42Z
Lists: pgsql-hackers
Attachments
- v1-0001-Add-new-tests-for-lock-stats.patch (text/x-diff)
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix injection point detach timing problem in TAP test for lock stats
- 3284e3f63cf0 19 (unreleased) landed
-
Use single LWLock for lock statistics in pgstats
- 404a17c155ac 19 (unreleased) landed
-
Add tests for lock statistics, take two
- 557a9f1e3e62 19 (unreleased) landed
-
Remove isolation test lock-stats
- 7c64d56fd976 19 (unreleased) landed
-
Avoid including clog.h in proc.h
- f227b7b20c36 19 (unreleased) landed
-
Don't include storage/lock.h in so many headers
- 2102ebb1953f 19 (unreleased) landed
-
Add support for lock statistics in pgstats
- 4019f725f5d4 19 (unreleased) landed
-
Move some code blocks in lock.c and proc.c
- a90d86518243 19 (unreleased) landed
-
Move declarations related to locktags from lock.h to new locktag.h
- 322bab79744d 19 (unreleased) landed