On Tue, Feb 3, 2009 at 7:04 PM, David Fetter <david@xxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
