From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Let's invent a function to report lock-wait-blocking PIDs |
Date: | 2013-03-20 23:03:21 |
Message-ID: | m2hak51xom.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Brendan Jurd | 2013-03-20 23:45:54 | [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL) |
Previous Message | Tom Lane | 2013-03-20 22:46:23 | Re: Let's invent a function to report lock-wait-blocking PIDs |