Re: Adding locks statistics

Michael Paquier <michael@paquier.xyz>

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
Date: 2026-02-19T04:06:52Z
Lists: pgsql-hackers
On Tue, Feb 17, 2026 at 04:33:54PM +0000, Bertrand Drouvot wrote:
> Okay, done that way in the attached. To avoid overhead due to timing as much as
> possible, the patch simply relies on log_lock_waits and deadlock_timeout. It means
> that it relies on the existing code, and increments waits and wait_time only if
> log_lock_waits is on and if the session waited longer than deadlock_timeout.
> 
> I did not want to dissociate the waits and wait_time increments so that their
> ratio could still make sense.
> 
> That sounds like a good compromise, thoughts?

             else if (myWaitStatus == PROC_WAIT_STATUS_OK)
+            {
+                /* Increment the lock statistics counters */
+                pgstat_count_lock_waits(locallock->tag.lock.locktag_type);
+                pgstat_count_lock_wait_time(locallock->tag.lock.locktag_type, msecs);

Not sure that it makes much sense to me to rely on log_lock_waits
being enabled to decide if this count and this time are aggregated.
The log information and the stats gathering are two separate things.
Wouldn't it make more sense to call pgstat_count_lock_waits() outside
of this code path, when we know myWaitStatus?

While relying on the time calculating for the logs data is a good
idea, it seems to me that we should have a separate GUC to enable this
number, like a new track_lock_timings?  If track_lock_timings or
log_lock_waits is enabled, we should calculate the time difference.
All these decisions also depends on what deadlock_state holds on top
of myWaitStatus, I guess..
--
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