From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Let's invent a function to report lock-wait-blocking PIDs |
Date: | 2013-03-22 09:39:13 |
Message-ID: | 514C26C1.1020001@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 21.03.2013 05:36, Tom Lane wrote:
> Simon Riggs<simon(at)2ndQuadrant(dot)com> writes:
>> On 20 March 2013 18:02, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> The API that comes to mind is (name subject to
>>> bikeshedding)
>>>
>>> pg_blocking_pids(pid int) returns int[]
>
>> Useful. Can we also have an SRF rather than an array?
>
> I thought about that, but at least for the isolationtester use-case,
> the array result is clearly easier to use. You can get from one to the
> other with unnest() or array_agg(), so I don't really feel a need to
> provide both. Can you generate use-cases where the set-result approach
> is superior?
How about inverting the function into:
pg_pid_blocked_by(pid int) returns int
It would take as argument a pid, and return the pid of the process that
is blocking the given process. That would feel more natural to me.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-03-22 10:33:39 | Re: Page replacement algorithm in buffer cache |
Previous Message | Basil Bourque | 2013-03-22 09:03:49 | Re: Call for Google Summer of Code mentors, admins |