Re: Add per-backend lock statistics

On Wed, Jun 03, 2026 at 01:58:41PM +0000, Bertrand Drouvot wrote:
> 0001: Refactor pg_stat_get_lock() to use a helper function
> 
> Extract the tuple-building logic from pg_stat_get_lock() into a new
> static helper pg_stat_lock_build_tuples().  This is in preparation for
> pg_stat_get_backend_lock() which will reuse the same helper, following
> the pattern established by pg_stat_io_build_tuples() for IO stats and
> pg_stat_wal_build_tuple() for WAL stats.

-        values[i] = TimestampTzGetDatum(lock_stats->stat_reset_timestamp);
+        if (stat_reset_timestamp != 0)
+            values[i] = TimestampTzGetDatum(stat_reset_timestamp);
+        else
+            nulls[i] = true;

Wait a minute here.  I was wondering for a couple of minutes if we
should do that on HEAD as well, but we have reset_after_failure that
would set it to a nice value for the persistent part of the data..
That looks OK.

> 0002: Add per-backend lock statistics

+/* used by pgstat_lock.c for lock stats tracked in backends */
+extern void pgstat_count_backend_lock_waits(uint8 locktag_type, long msecs);
+extern void pgstat_count_backend_lock_fastpath_exceeded(uint8 locktag_type);
 extern PgStat_Backend *pgstat_fetch_stat_backend(ProcNumber procNumber);

Nit.  pgstat_fetch_stat_backend() and routines listed below are not
related to pgstat_lock.c.  Add a newline perhaps?

I don't see much popping out on a closer read of 0002 (well, we've
discussed this patch and being able to see the balancing of lock
acquisitions across live backends is something that can be handy).  As
far as I can see, you rely on the same infra as what has been done for
IO and WAL.  Nice to see backend_has_lockstats being kept local to
pgstat_backend.c.
--
Michael