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/..." best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers