Alvaro Herrera <alvherre@commandprompt.com> writes:
> Humm, sorry, obviously this makes no sense at all because I mentally
> mixed the Xid locker and the Cids.
After thinking a bit, I have a sketch of a solution.
Assume that we extend the MultiXact infrastructure so that it can track
whether each member of a MultiXact holds shared or exclusive lock.
(There are a couple ways you could do that --- add a parallel bit-array,
or separate the members into two groups. Details not important for now.)
The only way you could have both shared- and exclusive-lock members is
if they are subtransactions of the same backend, but that fact isn't
real relevant to the MultiXact code.
Then extend MultiXactIdWait() so that you can tell it to wait for all
members to die, or just the exclusive members.
Then the representation of the problem situation would be that a locked
tuple would have as XMAX a MultiXact containing the upper XID as shared
locker and the subtransaction as exclusive locker. Onlookers could wait
for one or both to die as appropriate depending on what kind of lock
they needed to get. HEAP_XMAX_EXCL_LOCK would have to be a hint rather
than the truth, ie, once all the exclusive-lock members of the MultiXact
are dead it's really only a shared lock, but I don't see that this poses
any real difficulty.
I don't particularly want to go implement this now; I just want a
proof-of-concept sketch proving that we don't need separate cmin and
cmax to support this.
As for what I think we *should* do near-term, I'm pretty strongly
tempted to suggest that we just throw an error if a subtransaction tries
to upgrade an upper transaction's shared lock to exclusive. When and if
we get a ton of complaints about that, it'd be time to put forth effort
to fix it. I suspect the situation doesn't really arise much in
practice, else we'd have heard complaints from the field about the fact
that the shared lock can become lost.
Comments?
regards, tom lane
