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
