On Mon, Apr 18, 2005 at 08:00:57PM -0400, Tom Lane wrote:
> 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?
Ok, here is the patch again. I did this, so there are now two related
bits in the infomask: HEAP_XMAX_IS_MULTI and
HEAP_XMAX_{SHARED,EXCLUSIVE}_LOCK. (I ripped out HEAP_XMAX_FOR_UPDATE).
Locking and using a MultiXactId are orthogonal.
The rest is more or less the same that was in the original patch. I
feel this is in a OK state for review for possible inclusion. Some
testing is still needed regarding MultiXactId wraparound, and SLRU
truncation, and I haven't looked at whether documentation needs
updating.
--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
Jude: I wish humans laid eggs
Ringlord: Why would you want humans to lay eggs?
Jude: So I can eat them