Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
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>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
"Tharakan,
Robins" <tharar@amazon.com>
Date: 2024-05-16T17:47:37Z
Lists: pgsql-hackers, pgsql-general
Daniel Gustafsson <daniel@yesql.se> writes: >> On 5 Jul 2022, at 18:59, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. > (reviving an old thread from the TODO) > Since we never got around to doing this we still refer to 8.4 as a possible > upgrade path in v14 and older. Oh, yeah, that seems to have fallen through a crack. > The attached takes the conservative approach of raising the minimum supported > version to 9.0 while leaving the code to handle 8.4 in place. While it can be > removed, the risk/reward tradeoff of gutting code in backbranches doesn't seem > appealing since the code will be unreachable with this check anyways. Yeah, it's not worth working harder than this. I do see one typo in your comment: s/supported then/supported when/. LGTM otherwise. regards, tom lane
Commits
-
Refuse upgrades from pre-9.0 clusters
- ccf3408cff53 14.13 landed
- bcd2be0c2f7e 12.20 landed
- b030697d36d5 13.16 landed
-
pg_resetxlog: add option to set oldest xid & use by pg_upgrade
- 74cf7d46a91d 15.0 cited
-
Stamp 11.2.
- 6cd404b344f7 11.2 cited
-
Track the current XID wrap limit (or more accurately, the oldest unfrozen
- 25ec228ef760 9.0.0 cited