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.