Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-04-14 13:06:21 -0400, Tom Lane wrote:
>> In particular I'm not sold on the use-case
>> for being able to tell that a process is waiting without being able to
>> tell what it's waiting for. I can figure that much out already.
> You can? How? It could also be io or something else that's problematic.
If the process is not consuming any CPU time at all, it's waiting on
something. (Now admittedly, that might be hard to tell remotely ---
but Simon seems to be assuming you have access to "ps" output.)
>> One concrete reason not to do the proposed trivial hack is that the lock
>> readout views are asynchronous. Right now, if someone sees a process that
>> claims to be waiting but they don't see any entry in pg_locks, they know
>> they saw inconsistent state. If we add a valid state where waiting can be
>> true without a pg_locks entry, they won't know what to think. I don't
>> want to go there.
> What's you opinion of the waiting = true combined with waiting_for =
> 'cleanup lock' or something similar?
It's better than the original proposal, but it still doesn't tell you
which other processes are blocking the waiter, which makes it not
terribly useful IMO. Any actual gain in utility here would come from
being able to find that out.
regards, tom lane
