Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> The idea is that a tuple's Xmax can either be a real TransactionId
> (which is used normally like current CVS tip), or, if the infomask has
> HEAP_XMAX_SHARED_LOCK, a MultiXactId.
Interesting idea. Would it be possible to invoke this mechanism only
when actually needed --- that is, the first locker of a given tuple
puts his plain TransactionId into Xmax (and also sets an infomask bit
indicating his intent to have a shared rather than exclusive lock),
and then the second locker to come along replaces the TransactionId
with a MultiTransactionId including himself and the first locker?
This requires 2 infomask bits: 1 for shared vs exclusive lock and one
for whether the Xmax contains a TransactionId or MultiTransactionId.
But we have them available, and I think I like keeping those concepts
separate anyway. (Who's to say we wouldn't want to allow a
MultiTransactionId to hold an exclusive lock, someday?)
The advantage of course would be substantially less overhead in the very
common case where there's no actual contention for the tuple.
> MultiXactIds are implemented using two SLRU areas and a couple of
> variables in ShmemVariableCache. We also XLog groups of them just like
> we do for Oids.
So no need for expansible shmem storage? Might be the way to go.
I haven't read the patch yet but the idea sounds promising.
regards, tom lane