On Mon, Apr 18, 2005 at 09:53:38PM -0400, Bruce Momjian wrote: > Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> 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. > > Yes, that is certainly possible. Alvaro felt he wanted something > simpler and that the two-bit case would add complexity, but I agree it > would reduce overhead in the most common case.
I had thought it would make things more complicated. Now that I know how the whole thing works I can handle the extra complexity, which is not much really. Also I wasn't sure if we wanted to waste two infomask bits on this :-) > > > 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. Right. I have stashed some info (like next MultiXactId to assign, the first MultiXactId this transaction was assigned, etc) in ShmemVariableCache and PGPROC, but I'm now thinking in storing it in a [fixed size] shmem area private to multixact.c; this way I don't have to lock SInvalLock. BTW, I had to use three additional LWLocks: two for SLRU and one for MultiXactId generation, which also covers the ShmemVariableCache variables. I hope that's OK. -- Alvaro Herrera (<[EMAIL PROTECTED]>) "No es bueno caminar con un hombre muerto" ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
