Re: Let's invent a function to report lock-wait-blocking PIDs
От | Dimitri Fontaine |
---|---|
Тема | Re: Let's invent a function to report lock-wait-blocking PIDs |
Дата | |
Msg-id | m2hak51xom.fsf@2ndQuadrant.fr обсуждение исходный текст |
Ответ на | Re: Let's invent a function to report lock-wait-blocking PIDs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Let's invent a function to report lock-wait-blocking
PIDs
|
Список | pgsql-hackers |
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. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: