| From: | Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Alex Shapalov <shapalov(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Proposal: expose heavyweight lock wait start time in pg_stat_activity |
| Date: | 2026-09-21 22:58:05 |
| Message-ID: | CAN12+YKErWDGbhD=nV8+MXVs9vadJC11YYp10apajZKsJUTv6Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
>
> I'd like to propose exposing the start time of the current heavyweight lock wait in pg_stat_activity, perhaps as:
>
> lock_wait_start timestamptz
>
> pg_stat_activity currently tells us that a backend is waiting on a lock through wait_event_type and wait_event, but not when that wait started.
pg_locks.waitstart already provides this information. Any reason that
is not sufficient?
pg_locks is meant to be joined with pg_stat_activity anyhow. The two
views aren't read
from the same snapshot, so they can be out of sync. But that's already
true inside
pg_stat_activity, as the docs say:
"To keep the reporting overhead low, the system does
not attempt to synchronize different aspects of activity data for a
backend. As a result,
ephemeral discrepancies may exist between the view's columns."
The same will be true even if we add waitstart to pg_stat_activity.
--
Sami Imseih
Amazon Web Services (AWS)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-09-21 23:01:25 | Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring |
| Previous Message | Michael Paquier | 2026-09-21 22:56:08 | Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby |