Re: Let's invent a function to report lock-wait-blocking PIDs - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Let's invent a function to report lock-wait-blocking PIDs
Date
Msg-id CAM-w4HMOB4TOOc9Xm5BujrA1xYDQB3iYc5-xR8g2c2VAfZPiEw@mail.gmail.com
Whole thread Raw
In response to Let's invent a function to report lock-wait-blocking PIDs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Let's invent a function to report lock-wait-blocking PIDs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 20, 2013 at 6:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I propose that we should add a backend function that simplifies this
> type of query.  The API that comes to mind is (name subject to
> bikeshedding)
>
>         pg_blocking_pids(pid int) returns int[]

I've wanted to use pg_locks as a demonstration for recursive queries
many times and ran into the same problem. It's just too hard to figure
out which lock holders would be blocking which other locks.

I would like to be able to generate the full graph showing indirect
blocking. This seems to be not quite powerful enough to do it though.
I would have expected something that took whole pg_lock row values or
something like that.

-- 
greg



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: machine-parseable object descriptions
Next
From: Kevin Grittner
Date:
Subject: Re: Materialized view assertion failure in HEAD