Re: Need help understanding pg_locks

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Need help understanding pg_locks
Date: 2011-07-11 15:43:59
Message-ID: 0D6EFBE5-AB42-436E-BE6F-2C31ABE9288C@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

...

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-07-11 15:44:04 Re: per-column generic option
Previous Message Tom Lane 2011-07-11 15:41:05 Re: Need help understanding pg_locks