Thread

Re: Need help understanding pg_locks

Bruce Momjian <bruce@momjian.us> — 2011-07-14T17:06:09Z

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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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