On Tue, Feb 3, 2009 at 7:04 PM, David Fetter <david(at)fetter(dot)org> wrote:
>> Notably, there's no indication of which lock wait queue the
>> ungranted locks are in. That means to find out what's blocking a
>> lock would require comparing every other lock to it and deciding
>> whether it conflicts.
> Interesting :)
It would probably be more interesting if what I wrote made sense. I
think I mixed things up enoug that it doesn't though. I'll have to
read through the locking code and figure out the right way to say it
>> I haven't thought hard about the pros and cons of adding more info
>> to pg_locks versus implementing redundant logic in SQL to mirror C
>> code. Neither seems terribly enticing offhand.
>> I wonder if anybody else has already implemented something like
> Dunno. Could such a thing live in userland, or would it have to be
> compiled in?
Sure, it's just tedious and error-prone. You compare all the fields of
pg_locks and implement the same rules our locking code follows.
In response to
pgsql-general by date
|Next:||From: Greg Stark||Date: 2009-02-04 02:39:18|
|Subject: Re: Pet Peeves?|
|Previous:||From: Thomas Kellerer||Date: 2009-02-03 23:49:38|
|Subject: Re: getting column value length|