Re: Let's invent a function to report lock-wait-blocking PIDs

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

In response to

Responses

Browse pgsql-hackers by date

  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