Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers