On Tue, 12 Nov 2024 at 02:31, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> 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
--
Best regards,
Maxim Orlov.
v7-0001-Use-64-bit-format-output-for-multixact-offsets.patch
Description: Binary data
v7-0004-Get-rid-of-MultiXactMemberFreezeThreshold-call.patch
Description: Binary data
v7-0005-TEST-bump-catver.patch
Description: Binary data
v7-0003-Make-pg_upgrade-convert-multixact-offsets.patch
Description: Binary data
v7-0002-Use-64-bit-multixact-offsets.patch
Description: Binary data
