Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > Ok. I had hoped to reproduce the problem with pristine sources, in
> > order to verify that I was able to show it not appearing with my patch.
> > However I have been unable to create a situation in which the problem
> > appears. So I attach the patch that I came up with. Please test it.
>
> On further reflection, this isn't gonna work :-(. The problem with the
> waste-a-slot approach is that it creates an ambiguity near the offsets
> wraparound point: if you are looking at an mxid with starting offset
> just under 2^32, and you see the next mxid has start offset 1, did your
> mxid include the xid in offset 0 or not?
This is certainly a problem, but I think we can just assume that it did
and cope later with the possibility that it didn't. Which means that we
should allow GetMultiXactIdMembers() check whether one element is
InvalidTransactionId, and skip it if so. (AFAICS this should only happen
if the MultiXact members ends just before offset 0).
> I'm currently experimenting with an alternative approach, which leaves
> the nextOffset arithmetic as it was and instead special-cases the zero
> offset case this way:
I think I understand your approach, but I wonder why Matteo didn't find
an improvement with your patch. Maybe there's a bug on it?
Were you able to create a test case? I tried several things, including
stopping a backend in the middle of creating a MultiXactId, but no luck
yet.
--
Alvaro Herrera http://www.advogato.org/person/alvherre
"La Primavera ha venido. Nadie sabe como ha sido" (A. Machado)
