Re: Need help understanding pg_locks

Florian Pflug wrote:
> On Jul11, 2011, at 17:31 , Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Florian Pflug <fgp(at)phlo(dot)org> writes:
> >>> On Jul11, 2011, at 17:11 , Tom Lane wrote:
> >>>> Yeah, I think this patch is going in the wrong direction altogether.
> >>>> It would be better to modify the description of virtualtransaction
> >>>> and pid to say that those are the "locking" entity.
> >>
> >>> Hm, we already kinda of say that. Both descriptions include the phrase
> >>> "... holding or awaiting this lock.". The column "mode" says
> >>> "... held or desired by this process", which I guess is similar enough
> >>> to make it clear that these are related.
> >>
> >>> Its the columns which refer to the locked object which simply say
> >>> "object", and thus leave it open if that means locked or a locking.
> >>
> >>> Could we split that table in two parts, one for the fields referring
> >>> to the locked object and one for the locking entity, or does that depart
> >>> too far from the way we document other system catalogs and views?
> >>
> >> Then you'd have to join them, which would not be an improvement from
> >> anybody's standpoint.
> >>
> >> Maybe we could just add a paragraph above the "pg_locks Columns" table
> >> that says explicitly that virtualtransaction and pid describe the entity
> >> holding or awaiting the lock, and the others describe the object being
> >> locked? Any way you slice it, putting this information into the
> >> per-column table is going to be repetitive.
> >
> > Frankly, whenever anyone says "object", they might as well call it
> > "thing". It seems to be a content-less word. Maybe just replace the
> > word "object" with "lock".
>
> I like that, as long as we make it ".. lock is/isn't *on* a ...", and not
> just "... lock is/isn't a". After all, the lock very clearly isn't a
> relation or xid or whatever - it's a, well, lock.
>
> We'd then have
> OID of the database in which the lock exists, or zero if the lock is on a
> shared object, or null if the lock is on a transaction ID.
>
> OID of the relation, or null if the lock is not on a relation or part of a
> relation.
>
> ...
>
> ID of a transaction, or null if the lock is not on a transaction ID

OK, I went with this wording, using "lock object is on" terminology.
Applied patch attached --- adjustments welcomed.

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

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