Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> 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) ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
