Re: Need help understanding pg_locks
От | Florian Pflug |
---|---|
Тема | Re: Need help understanding pg_locks |
Дата | |
Msg-id | 0D6EFBE5-AB42-436E-BE6F-2C31ABE9288C@phlo.org обсуждение исходный текст |
Ответ на | Re: Need help understanding pg_locks (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Need help understanding pg_locks
|
Список | pgsql-hackers |
On Jul11, 2011, at 17:31 , Bruce Momjian wrote: > Tom Lane wrote: >> Florian Pflug <fgp@phlo.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 lockis 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
В списке pgsql-hackers по дате отправления: