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

From Jonathan S. Katz
Subject Re: pg15b2: large objects lost on upgrade
Date
Msg-id 98286e9b-8fe6-554e-c23f-d67a3df2c30d@postgresql.org
Whole thread Raw
In response to Re: pg15b2: large objects lost on upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg15b2: large objects lost on upgrade
List pgsql-hackers
On 8/2/22 3:39 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> On 8/2/22 3:23 PM, Robert Haas wrote:
>>> I'm not quite sure how to rule that theory in or out, though.
> 
>> Without overcomplicating this, are we able to check to see if autovacuum
>> ran during the course of the test?
> 
> Looks like we're all thinking along the same lines.
> 
> While not smoking guns, these definitely prove that autovac was active.

 > 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.

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?

Jonathan

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg15b2: large objects lost on upgrade
Next
From: Tom Lane
Date:
Subject: Re: pg15b2: large objects lost on upgrade