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: Bruce Momjian <bruce@momjian.us>
Cc: "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-05T16:59:42Z
Lists: pgsql-hackers, pgsql-general 
Bruce Momjian <bruce@momjian.us> writes:
> This patch has been applied back to 9.6 and will appear in the next
> minor release.

I have just discovered that this patch broke pg_upgrade's ability
to upgrade from 8.4:

$ pg_upgrade -b ~/version84/bin -d ...
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
The source cluster lacks some required control information:
  latest checkpoint oldestXID

Cannot continue without required control information, terminating
Failure, exiting

Sure enough, 8.4's pg_controldata doesn't print anything about
oldestXID, because that info wasn't there then.

Given the lack of field complaints, it's probably not worth trying
to do anything to restore that capability.  But we really ought to
update pg_upgrade's code and docs in pre-v15 branches to say that
the minimum supported source version is 9.0.

			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