Re: Proposal: expose heavyweight lock wait start time in pg_stat_activity

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
Cc: Alex Shapalov <shapalov(at)gmail(dot)com>, 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 23:58:56
Message-ID: CAGRkXqR+WkkRowsucXwb_ncZvNAm4dqU5TBa2Asjro2W2spDNw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alex,

> pg_locks.waitstart already provides this information. Any reason that
> is not sufficient?

I agree with Sami here. A backend waits on at most one lock at a time,
so a view on your side gives you the same thing today:

CREATE VIEW my_activity AS
SELECT a.*, l.waitstart AS lock_wait_start
FROM pg_stat_activity a
LEFT JOIN pg_locks l ON l.pid = a.pid AND NOT l.granted;

The only thing that view cannot give you is avoiding the lock manager
scan pg_locks does on every read. I do not think that is an issue
unless something queries the view very often, like a monitoring agent
sampling every second. If that is your case, please show numbers for
it. That is the case the patch would need to make.

Thanks,
Shihao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-09-22 00:07:21 Re: Support for 8-byte TOAST values, round two
Previous Message shihao zhong 2026-09-21 23:54:04 Re: Add a permission check to pg_stat_get_backend_subxact()