Re: Let's invent a function to report lock-wait-blocking PIDs
От | Bruce Momjian |
---|---|
Тема | Re: Let's invent a function to report lock-wait-blocking PIDs |
Дата | |
Msg-id | 20130325195118.GE17029@momjian.us обсуждение исходный текст |
Ответ на | Re: Let's invent a function to report lock-wait-blocking PIDs (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Список | pgsql-hackers |
On Thu, Mar 21, 2013 at 12:03:21AM +0100, Dimitri Fontaine wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > >> pg_is_lock_exclusive(lock, lock) returns boolean > >> pg_is_lock_exclusive(lock[], lock[]) returns boolean > > > >> I suppose that the lock type would be text ('ExclusiveLock'), but we > >> could also expose a new ENUM type for that (pg_lock_mode). > > > > I don't have an objection to providing such a function, but it doesn't > > do anything for the problem beyond allowing getting rid of the hairy > > case expression. That's a good thing to do of course --- but what about > > the indirect-blockage issue? > > It's too late for my brain to build the full answer, the idea is that we > have another way to build the dependency cycles in the pg_locks query > and then we can aggregate locks at each level and see about conflicts > once we accumulated the data. > > Is that even possible? E_GOTOSLEEP. Should this be a TODO? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: