Re: Adding locks statistics

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Greg Sabino Mullane <htamfids@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2026-04-06T06:34:44Z
Lists: pgsql-hackers

Attachments

On Mon, Apr 06, 2026 at 03:19:57PM +0900, Michael Paquier wrote:
> Now looking at it, and for the reason why 010 for concurrent indexes
> does not complain..

This one was a simple puzzle: there was a race condition between the
detach done by a local point and the wait/detach sequence.  As we want
a detach, dropping the local point is proving to work here.

I am going to do a few more runs to gain some more confidence.
Bertrand, could you confirm please?
--
Michael

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix injection point detach timing problem in TAP test for lock stats

  2. Use single LWLock for lock statistics in pgstats

  3. Add tests for lock statistics, take two

  4. Remove isolation test lock-stats

  5. Avoid including clog.h in proc.h

  6. Don't include storage/lock.h in so many headers

  7. Add support for lock statistics in pgstats

  8. Move some code blocks in lock.c and proc.c

  9. Move declarations related to locktags from lock.h to new locktag.h