Re: pg15b2: large objects lost on upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg15b2: large objects lost on upgrade
Date
Msg-id 2687956.1659469881@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg15b2: large objects lost on upgrade  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: pg15b2: large objects lost on upgrade
Re: pg15b2: large objects lost on upgrade
List pgsql-hackers
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 8/2/22 3:39 PM, Tom Lane wrote:
>>> 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.

> The test does look helpful and it would catch regressions. Loosely 
> quoting Robert on a different point upthread, we don't want to turn off 
> the alarm just because it's spuriously going off.
> I think the weakened check is OK (and possibly mimics the real-world 
> where autovacuum runs), unless you see a major drawback to it?

I also think that ">=" is a sufficient requirement.  It'd be a
bit painful to test if we had to cope with potential XID wraparound,
but we know that these installations haven't been around nearly
long enough for that, so a plain ">=" test ought to be good enough.
(Replacing the simple "eq" code with something that can handle that
doesn't look like much fun, though.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: pg15b2: large objects lost on upgrade
Next
From: Thomas Munro
Date:
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)