On Tue, Feb 3, 2009 at 7:04 PM, David Fetter <david@fetter.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
tomorrow.
>> 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
>> lock_conflicts()?
>
> 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.
--
greg