Re: Add per-backend lock statistics

From: Tatsuya Kawata <kawatatatsuya0913(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add per-backend lock statistics
Date: 2026-06-24 13:49:44
Message-ID: CAHza6qfMC7hVp-LqcqTXV9XQP5G9HyeJVgDBqY-m6bqZxjQyKw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Bertrand-san,

I tested the patch locally and did not find any functional issue.
I have two suggestions below.

== Doc suggestion ==

When the workload uses parallel scans, pg_stat_lock.fastpath_exceeded
grows more than what pg_stat_get_backend_lock shows for any
individual pid. The gap is the parallel workers' contribution:
each worker locks the valid subplans independently, accumulates into
its own per-backend entry, and the entry is dropped at worker exit
-- so the contribution is not folded into the leader's per-backend
view.

This is a property of the per-backend stats infrastructure rather
than something this patch introduces, but since one of the stated
motivations is "Isolate problematic sessions", users may
intuitively expect parallel-worker contributions to be visible
under the leader's pid. A short note in the docs of the per-backend
functions clarifying that
parallel-worker contributions are not aggregated into the leader's
entry would help avoid that misunderstanding.

== Column suggestion for pg_stat_lock ==

pg_stat_io has a backend_type column, which lets users still see
parallel-worker contributions in aggregate (via WHERE
backend_type='background worker') after workers exit. pg_stat_lock
has only locktype, so worker contributions blend into the relation
row and cannot be separated even in aggregate.

This may be out of scope for the present patch, but I wonder if
adding a backend_type axis to pg_stat_lock could be considered in a
follow-up patch. It would give an alternative attribution path
(similar to pg_stat_io's backend_type column) when per-backend
statistics cannot help.

Regards,
Tatsuya Kawata

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2026-06-24 13:56:41 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Shlok Kyal 2026-06-24 13:27:44 Re: [PATCH] Preserve replication origin OIDs in pg_upgrade