Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't see any easy way to fix this except by introducing a lot more
>> locking than is there now --- ie, holding the MultiXactGenLock until the
>> new mxact's starting offset has been written to disk. Any better ideas?
> Well, it isn't a very good solution because it requires us to retain the
> MultiXactGenLock past a XLogInsert and some I/O on SLRU pages.
Yeah :-(. If MultiXactGenLock wasn't a bottleneck before, it will soon
become one.
> I confess being attracted to Martijn's idea of looping until the correct
> answer is obtained. I don't think it's even too difficult to implement.
> But I wonder if there's some hidden pitfall.
I've been looking at that and I think it can work. The key point is
that GetNewMultiXactId() does guarantee that space has been allocated
for the new mxact's offset before it releases the lock (else we'd risk
trying to read a nonexistent slru page when we fetch the offset in
GetMultiXactIdMembers). And we are careful to zero out newly allocated
space. So it should be safe to assume that the offset will be zero if
it hasn't been initialized yet. So we could loop if we see zero.
We'd have to make sure zero is never the *correct* value of the offset,
but that just means wasting one word, which seems no problem.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: 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
