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. > 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly