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

Reply via email to