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 f0c60283-1c3d-0f0e-166a-b667c154fe0a@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
Re: pg15b2: large objects lost on upgrade
List pgsql-hackers
On 8/3/22 4:19 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> I did rule out wanting to do the "xid + $X" check after reviewing some
>> of the output. I think that both $X could end up varying, and it really
>> feels like a bandaid.
> 
> It is that.  I wouldn't feel comfortable with $X less than 100 or so,
> which is probably sloppy enough to draw Robert's ire.  Still, realizing
> that what we want right now is a band-aid for 15beta3, I don't think
> it's an unreasonable short-term option.

Attached is the "band-aid / sloppy" version of the patch. Given from the 
test examples I kept seeing deltas over 100 for relfrozenxid, I chose 
1000. The mxid delta was less, but I kept it at 1000 for consistency 
(and because I hope this test is short lived in this state), but can be 
talked into otherwise.

>> Andres suggested upthread using "txid_current()" -- for the comparison,
>> that's one thing I looked at. Would any of the XID info from
>> "pg_control_checkpoint()" also serve for this test?
> 
> I like the idea of txid_current(), but we have no comparable
> function for mxid do we?  While you could get both numbers from
> pg_control_checkpoint(), I doubt that's sufficiently up-to-date.

...unless we force a checkpoint in the test?

Jonathan
Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Introduce wait_for_subscription_sync for TAP tests
Next
From: Robert Haas
Date:
Subject: Re: pg15b2: large objects lost on upgrade