From: | Greg Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Pet Peeves? |
Date: | 2009-02-04 02:37:43 |
Message-ID: | 4136ffa0902031837m66c847dbk4ccb0c5948c27d4d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-02-04 02:39:18 | Re: Pet Peeves? |
Previous Message | Thomas Kellerer | 2009-02-03 23:49:38 | Re: getting column value length |