On Mon, Aug 8, 2022 at 09:51:46PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > >> Hmmm ... now that you mention it, I see nothing in 002_pg_upgrade.pl > >> that attempts to turn off autovacuum on either the source server or > >> the destination. So one plausible theory is that autovac moved the > >> numbers since we checked. > > > Uh, pg_upgrade assumes autovacuum is not running, and tries to enforce > > this: > > The problems come from autovac running before or after pg_upgrade. > > > Perhaps the test script should do something similar, > > I'm not on board with that, for the reasons I gave upthread.
Uh, I assume it is this paragraph: > If that is the explanation, then it leaves us with few good options. > I am not in favor of disabling autovacuum in the test: ordinary > users are not going to do that while pg_upgrade'ing, so it'd make > the test less representative of real-world usage, which seems like > a bad idea. We could either drop this particular check again, or > weaken it to allow new relfrozenxid >= old relfrozenxid, likewise > relminxid. I thought the test was setting up a configuration that would never be used by normal servers. Is that false? -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Indecision is a decision. Inaction is an action. Mark Batterson
