Re: Need help understanding pg_locks

Florian Pflug wrote:
> On Jul13, 2011, at 21:08 , Bruce Momjian wrote:
> > - OID of the database in which the object exists, or
> > - zero if the object is a shared object, or
> > - null if the lock object is on a transaction ID
> > + OID of the database in which the lock target exists, or
> > + zero if the lock is a shared object, or
> > + null if the lock is on a transaction ID
>
> This sounds good.
>
> > + OID of the relation lock target, or null if the lock is not
> > on a relation or part of a relation
>
> That, however, not so much. "relation lock target" might easily
> be interpreted as the "relation's lock target" or the
> "relation lock's target" - at least by non-native speakers such
> as myself. The same is true fro "transaction lock target" and
> friends.
>
> Can't we simply go with "Locked relation", "Locked transaction id"
> and so on (as in my versions B,C and D up-thread)? I can't really
> get excited about the slight imprecision caused by the fact that some
> rows describe aspiring lock holders instead of current lock holders.
> The existence of the "granted" column makes the situation pretty clear.
>
> Plus, it's technically not even wrong - a process is waiting because
> somebody else *is* actually holding a lock on the object. So
> the tuple/transaction/... is, in fact, a "Locked tuple/transaction/..."

I think it will be very confusing to have "locked" refer to the person
holding the lock while the row is based on who is waiting for it.

I reworded that line to:

+ OID of the relation of the lock target, or null if the lock is not

Update patch attached.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +