> We'd still want XID keys for the locks that are used to wait for a
> particular transaction to complete (eg when waiting to update 
> a tuple). I think that's OK since VACUUM doesn't need to hold any
> such locks, but it'd probably mean making separate lmgr API entry
> points for those locks as opposed to normal table-level locks.

In this case XID is used as key in LOCKTAG, ie in lock identifier,
but we are going to change XIDTAG, ie just holder identifier.
No new entry will be required.

Vadim

Fri, 15 Dec 2000 14:44:33 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: TOAST-table vacuuming (was Re: Idea for reducing pl anning time) 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
>> We'd still want XID keys for the locks that are used to wait for a
>> particular transaction to complete (eg when waiting to update 
>> a tuple). I think that's OK since VACUUM doesn't need to hold any
>> such locks, but it'd probably mean making separate lmgr API entry
>> points for those locks as opposed to normal table-level locks.

> In this case XID is used as key in LOCKTAG, ie in lock identifier,
> but we are going to change XIDTAG, ie just holder identifier.
> No new entry will be required.

Oh, OK.  What say I rename the data structure to HOLDERTAG or something
like that, so it's more clear what it's for?  Any suggestions for a
name?

			regards, tom lane

Fri, 15 Dec 2000 18:08:08 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: TOAST-table vacuuming (was Re: Idea for reducing pl anning time) 