Hi,
On Wed, Jun 24, 2026 at 02:57:47PM +0900, Michael Paquier wrote:
> 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..
Right and per-backend stats are not written to disk, hence the need here.
>
> > 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?
Yeah. This is not introduced by the patch, as it's currently not related to
pgstat_io.c on HEAD either, but let's clean it in passing. Done in v2 (that's
the only change compared to v1).
> far as I can see, you rely on the same infra as what has been done for
> IO and WAL.
Right.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
