The wraparound logic is still not correct.
Yep, my fault. I forget to reset segment counter if wraparound is happened. Fixed.
When I try to select from a table after upgrade that contains
post-wraparound multixids:
TRAP: failed Assert("offset != 0"), File:
"../src/backend/access/transam/multixact.c", Line: 1353, PID: 63386
The problem was in converting offset segments. The new_entry index should also bypass the invalid offset (0) value. Fixed.
On a different note, I'm surprised you're rewriting member segments from
scratch, parsing all the individual member groups and writing them out
again. There's no change to the members file format, except for the
numbering of the files, so you could just copy the files under the new
names without paying attention to the contents. It's not wrong to parse
them in detail, but I'd assume that it would be simpler not to.
Yes, at the beginning I also thought that it would be possible to get by with simple copying. But in case of wraparound, we must "bypass" invalid zero offset value. See, old 32 bit offsets a wrapped at 2^32, thus 0 values appears in multixact.c So, they must be handled. Bypass, in fact. When we are switched to the 64-bit offsets, we have two options:
1). Bypass every ((uint32) offset == 0) value in multixact.c;
2). Convert members and bypass invalid value once.
The first options seem too weird for me. So, we have to repack members and bypass invalid value.
All patches are for master@38c18710b37a2d