On 07/09/2024 07:36, Maxim Orlov wrote:
Here is v3.
MultiXactMemberFreezeThreshold looks quite bogus now. Now that MaxMultiXactOffset==2^64-1, you cannot get anywhere near the MULTIXACT_MEMBER_SAFE_THRESHOLD and MULTIXACT_MEMBER_DANGER_THRESHOLD values anymore. Can we just get rid of MultiXactMemberFreezeThreshold? I guess it would still be useful to trigger autovacuum if multixacts members grows large though, to release the disk space, even if you can't run out of members as such anymore. What should the logic for that look like?
I'd love to see some tests for the pg_upgrade code. Something like a little perl script to generate test clusters with different wraparound scenarios etc. using the old version, and a TAP test to run pg_upgrade on them and verify that queries on the upgraded cluster works correctly. We don't have tests like that in the repository today, and I don't know if we'd want to commit these permanently either, but it would be highly useful now as a one-off thing, to show that the code works.
On upgrade, are there really no changes required to pg_multixact/members? I imagined that the segment files would need to be renamed around wraparound, so that if you previously had files like this:
pg_multixact/members/FFFE pg_multixact/members/FFFF pg_multixact/members/0000 pg_multixact/members/0001 after upgrade you would need to have: pg_multixact/members/00000000FFFE pg_multixact/members/00000000FFFF pg_multixact/members/000000010000 pg_multixact/members/000000010001 Thanks for working on this! -- Heikki Linnakangas Neon (https://neon.tech)
