From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
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 22:46:23 |
Message-ID: | 25576.1363819583@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> If we want a global view of the who-blocks-whom situation, I think we'll
>> need another approach. But since this way solves isolationtester's
>> problem fairly neatly, I was hopeful that it would be useful for other
>> apps too.
> What about a function
> 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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2013-03-20 23:03:21 | Re: Let's invent a function to report lock-wait-blocking PIDs |
Previous Message | Kevin Grittner | 2013-03-20 22:40:55 | Re: Materialized view assertion failure in HEAD |