Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date
Msg-id 20150826185558.GD29674@momjian.us
Whole thread Raw
In response to Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On Mon, Jul 27, 2015 at 04:10:14PM -0500, Jim Nasby wrote:
> >>Sure, but I don't think this makes it impossible to figure out who's
> >>locking who.  I think the only thing you need other than the data in
> >>pg_locks is the conflicts table, which is well documented.
> >>
> >>Oh, hmm, one thing missing is the ordering of the wait queue for each
> >>locked object.  If process A holds RowExclusive on some object, process
> >>B wants ShareLock (stalled waiting) and process C wants AccessExclusive
> >>(also stalled waiting), who of B and C is woken up first after A
> >>releases the lock depends on order of arrival.
> >
> >Agreed - it would be nice to expose that somehow.
> 
> +1. It's very common to want to know who's blocking who, and not at
> all easy to do that today. We should at minimum have a canonical
> example of how to do it, but something built in would be even
> better.

Coming in late here, but have you looked at my locking presentation;  I
think there are examples in there:
http://momjian.us/main/writings/pgsql/locking.pdf

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: 9.5 release notes
Next
From: Bruce Momjian
Date:
Subject: Re: 9.5 release notes