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 22:28:11 |
Message-ID: | m2r4j91zb8.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:
>>> I propose that we should add a backend function that simplifies this
>>> type of query. The API that comes to mind is (name subject to
>>> bikeshedding)
>>>
>>> pg_blocking_pids(pid int) returns int[]
+1
> 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). If we do
that, we can also provide operators such as the following… I did try to
search for some existing ones but failed to do so.
pg_lock_mode & pg_lock_mode
pg_lock_mode | pg_lock_mode
Equiped with that, it should be possible to come up with a recursive
query on pg_locks that displays the whole graph, and we should then
provide as one of our system views.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-03-20 22:40:55 | Re: Materialized view assertion failure in HEAD |
Previous Message | Dimitri Fontaine | 2013-03-20 22:14:05 | Re: [HACKERS] Call for Google Summer of Code mentors, admins |