From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: reporting reason for certain locks |
Date: | 2010-11-25 16:14:11 |
Message-ID: | 13392.1290701651@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> On the other hand, pg_locks is already rather unwieldy to use. We
> already have a self-join that tells us the details of what's locking
> processes: you need to join pg_locks like this:
> ...
> and throw in a bunch of left joins to see the details of database,
> relation, etc.
Sure. I'm just suggesting one more left join to see if there's a tuple
lock.
> This works fine for all kinds of locks except xid and
> vxid ones. I don't think it's fair to users to expect that they need to
> deal with that mess *plus* the details of tuple locks.
Well, what was in the back of my mind was that we should create a join
of this sort as a stock system view, which would certainly improve
usability across the board. Getting to consensus on exactly what the
view should contain might be hard though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-25 16:18:23 | Re: SQL/MED - core functionality |
Previous Message | Bruce Momjian | 2010-11-25 16:06:25 | problem with Win32 buildfarm |