Re: LockObject patch

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> On Mon, Dec 20, 2004 at 03:09:31PM -0500, Tom Lane wrote:
>> I wonder whether it wouldn't be possible to clean up the "XactLockTable"
>> kluge with this --- ie, instead of denoting transaction locks by a
>> special relation ID, denote them by a special class ID. That might just
>> move the kluginess from one place to another, but it's worth thinking about.

> How about locking the special class InvalidOid? We don't use that ATM
> AFAICS.

No, that's not an improvement --- if the solution doesn't allow multiple
classes of objects then we've not made any step forward.

We probably ought to step back and think about what objects we need to
be able to lock and what the identifying values are for each kind of
object. Offhand I think we have:

Whole relations:
DBID, REL OID (with special case DBID=0 for shared rels)
Pages within rels:
DBID, REL OID, BLOCKNUM (same special case)
Individual tuples (assuming we go the lockmanager route for this):
DBID, REL OID, BLOCKNUM, OFFNUM (same special case)
Transactions:
XID (would sub-XID be of any use??)
Non-relation objects:
DBID, CLASS OID, OBJECT OID, OBJECT SUBID
(it's reasonable to use DBID=0 for shared objects, eg users)
(we could possibly dispense with subid but for now let's
assume the same representation as in pg_depend and pg_description)
Userlocks:
DBID, ID1, ID2
(current implementation limits ID1 to 16 bits, but we could
widen that if we wanted)

Basically I think what we've got to decide is how to overlay these
fields and how to tell the six cases apart.

Since subids and offnums are only 16 bits, we could pack all of these
cases into 64 bits with a 16-bit type identifier to distinguish the
cases. That would mean that LOCKTAG doesn't get any bigger than it is
now, and we'd have plenty of room for expansion still with more types.

regards, tom lane