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
