On Sun, May 16, 2021 at 04:23:02PM -0400, Tom Lane wrote: > And the reason oldestXID contains that is that pg_upgrade applied > pg_resetwal, which does this: > > /* > * For the moment, just set oldestXid to a value that will force > * immediate autovacuum-for-wraparound. It's not clear whether adding > * user control of this is useful, so let's just do something that's > * reasonably safe. The magic constant here corresponds to the > * maximum allowed value of autovacuum_freeze_max_age. > */ > ControlFile.checkPointCopy.oldestXid = set_xid - 2000000000; > if (ControlFile.checkPointCopy.oldestXid < FirstNormalTransactionId) > ControlFile.checkPointCopy.oldestXid += FirstNormalTransactionId; > > So it seems like we should do some combination of these things: > > 1. Fix FullXidRelativeTo to be a little less trusting. It'd > probably be sane to make it return FirstNormalTransactionId > when it'd otherwise produce a wrapped-around FullXid, but is > there any situation where we'd want it to throw an error instead? > > 2. Change pg_resetwal to not do the above. It's not entirely > apparent to me what business it has trying to force > autovacuum-for-wraparound anyway, but if it does need to do that, > can we devise a less klugy method?
Sorry, I wish I could help with this pg_upgrade problem, but I have no idea why pg_resetwal is doing that. Pg_upgrade is supposed to be turning off autovacuum, though I think we have had some cases where it could not be fully turned off and consumption of many xids caused autovacuum to run and break pg_upgrade. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
