Horton

Re: [UNVERIFIED SENDER] Re: pg_upgrade can result in early wraparound on databases with high transaction load

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>, "Drouvot, Bertrand" <bdrouvot@amazon.com>, Andres Freund <andres@anarazel.de>, Justin Pryzby <pryzby@telsasoft.com>, Noah Misch <noah@leadboat.com>, Jason Harvey <jason@reddit.com>, Peter Geoghegan <pg@bowt.ie>, pgsql-hackers@postgresql.org, "Tharakan, Robins" <tharar@amazon.com>
Date: 2022-07-05T19:17:38Z
Lists: pgsql-hackers, pgsql-general 
Andrew Dunstan <andrew@dunslane.net> writes:
> So it's taken us a year to discover the issue :-( Perhaps if we're going
> to say we support upgrades back to 9.0 we should have some testing to be
> assured we don't break it without knowing like this. I'll see if I can
> coax crake to do that - it already tests back to 9.2.

Hmm ... could you first look into why 09878cdd4 broke it?  I'd supposed
that that was just detecting situations we must already have dealt with
in order for the pg_upgrade test to work, but crake's not happy.

			regards, tom lane

Commits

  1. Refuse upgrades from pre-9.0 clusters

  2. pg_resetxlog: add option to set oldest xid & use by pg_upgrade

  3. Stamp 11.2.

  4. Track the current XID wrap limit (or more accurately, the oldest unfrozen