On Tue, 22 Oct 2024 at 12:43, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> 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? > Yep, you're totally correct. The MultiXactMemberFreezeThreshold call is not necessary any more and can be safely removed. I made this as a separate commit in v4. But, as you rightly say, it will be useful to trigger autovacuum in some cases. The obvious place for this machinery is in the GetNewMultiXactId. I imagine this like "if nextOff - oldestOff > threshold kick autovac". So, the question is: what kind of threshold we want here? Is it a hard coded define or GUC? If it is a GUC (32–bit), what values should it be? And the other issue I feel a little regretful about. We still must be holding MultiXactGenLock in order to track oldestOffset to do "nextOff - oldestOff" calculation. > > 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. Agree. I'll address this as soon as I can. -- Best regards, Maxim Orlov.
v4-0004-Make-pg_upgrade-convert-multixact-offsets.patch
Description: Binary data
v4-0003-Get-rid-of-MultiXactMemberFreezeThreshold-call.patch
Description: Binary data
v4-0001-Use-64-bit-format-output-for-multixact-offsets.patch
Description: Binary data
v4-0002-Use-64-bit-multixact-offsets.patch
Description: Binary data
