"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> Use BackendID instead of XID in XIDTAG?
> Add internal (ie per backend) hash of locks that should not be
> released at commit time?
> And couple additional funcs in lmgr API?
I think that would work. I'm inclined to use backend PID instead of
BackendID in XIDTAG, because that way you could tell if a lock entry
is stale even after the BackendID gets recycled to a new process.
(Of course PIDs get recycled too, but not as fast as BackendIDs.)
Besides, PID is already being used by the USERLOCK case, and we could
eliminate some #ifdefs by making the two cases the same.
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.
Error cleanup should release all locks including those marked as
surviving the current xact. (We'd need to improve that when we
start to work on nested xacts, but it'll do for now.)
Other than that, it seems like it'd work, and it'd allow us to do a
normal transaction commit internally in VACUUM, which is a lot cleaner
than what VACUUM does now.
Comments, better ideas, anyone?
I can work on this if you don't have time to...
regards, tom lane
