Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Bruce Momjian |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | 20150826185558.GD29674@momjian.us обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Список | 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 по дате отправления: