From: Daniel Gustafsson <daniel@yesql.se>
Message-Id: <ECFFD994-D2A9-4E74-A607-01AF4C252340@yesql.se>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_8E1F4B01-26B5-4AA5-91D7-740295A9FDB8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))
Subject: Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on
 databases with high transaction load
Date: Thu, 16 May 2024 08:11:37 +0200
In-Reply-To: <1973418.1657040382@sss.pgh.pa.us>
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>
To: Tom Lane <tgl@sss.pgh.pa.us>
References: <CALSof1GM6i21BLr8PsFiRYazakojvesdc+_MiR-L_V5NNkRuWg@mail.gmail.com>
 <CAH2-Wz=9Cj8H0=GAiHducPETWf6ZXEzjk_pFkjPWnWH6hptpLA@mail.gmail.com>
 <20190615183759.GB239428@rfd.leadboat.com>
 <20210423234256.hwopuftipdmp3okf@alap3.anarazel.de>
 <20210424002827.GO7256@telsasoft.com>
 <20210424010005.fttcfskp3unr4jiu@alap3.anarazel.de>
 <fe006d56-85f1-5f1e-98e7-05b53dff4f51@amazon.com>
 <78bf65ea-517a-51ed-947b-9728a6ace513@amazon.com>
 <20210727023904.GA19774@momjian.us> <1973418.1657040382@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/ECFFD994-D2A9-4E74-A607-01AF4C252340%40yesql.se>
Precedence: bulk


--Apple-Mail=_8E1F4B01-26B5-4AA5-91D7-740295A9FDB8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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

There seems to be two alternatives here, either we bump the minimum =
version in
v14-v12 to 9.0 which is the technical limitation brought by 695b4a113ab, =
or we
follow the direction taken by e469f0aaf3c and set 9.2.  e469f0aaf3c =
raised the
minimum supported version to 9.2 based on the complexity of compiling =
anything
older using a modern toolchain.

It can be argued that making a change we don't cover with testing is =
unwise,
but we clearly don't test the current code either since it's broken.

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.

Thoughts?

--
Daniel Gustafsson


--Apple-Mail=_8E1F4B01-26B5-4AA5-91D7-740295A9FDB8
Content-Disposition: attachment;
	filename=0001-Refuse-upgrades-from-pre-9.0-clusters.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="0001-Refuse-upgrades-from-pre-9.0-clusters.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=20d0b747eb43980e4e639fd3844357e0ccbffbd705=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20Daniel=20Gustafsson=20=
<dgustafsson@postgresql.org>=0ADate:=20Thu,=2016=20May=202024=2007:43:50=20=
+0200=0ASubject:=20[PATCH]=20Refuse=20upgrades=20from=20pre-9.0=20=
clusters=0A=0ACommit=20695b4a113ab=20added=20a=20dependency=20on=20=
retrieving=20oldestxid=20from=0Apg_control,=20which=20only=20exists=20in=20=
9.0=20and=20onwards,=20but=20the=20check=20for=0A8.4=20as=20the=20oldest=20=
version=20was=20retained.=20Since=20there=20has=20been=20few=20if=0Aany=20=
complaints=20of=208.4=20upgrades=20not=20working,=20fix=20by=20setting=20=
9.0=20as=0Athe=20oldest=20version=20supported=20rather=20than=20=
resurrecting=208.4=20support.=0A=0ABackpatch=20to=20all=20supported=20=
versions.=0A=0ADiscussion:=20=
https://postgr.es/m/1973418.1657040382@sss.pgh.pa.us=0A=
Backpatch-through:=20v12=0A---=0A=20doc/src/sgml/ref/pgupgrade.sgml=20|=20=
2=20+-=0A=20src/bin/pg_upgrade/check.c=20=20=20=20=20=20|=209=20=
+++++++--=0A=202=20files=20changed,=208=20insertions(+),=203=20=
deletions(-)=0A=0Adiff=20--git=20a/doc/src/sgml/ref/pgupgrade.sgml=20=
b/doc/src/sgml/ref/pgupgrade.sgml=0Aindex=20d401053edf..8add90e8ed=20=
100644=0A---=20a/doc/src/sgml/ref/pgupgrade.sgml=0A+++=20=
b/doc/src/sgml/ref/pgupgrade.sgml=0A@@=20-67,7=20+67,7=20@@=20PostgreSQL=20=
documentation=0A=20=20</para>=0A=20=0A=20=20=20<para>=0A-=20=20=20=
pg_upgrade=20supports=20upgrades=20from=208.4.X=20and=20later=20to=20the=20=
current=0A+=20=20=20pg_upgrade=20supports=20upgrades=20from=209.0.X=20=
and=20later=20to=20the=20current=0A=20=20=20=20major=20release=20of=20=
<productname>PostgreSQL</productname>,=20including=20snapshot=20and=20=
beta=20releases.=0A=20=20=20</para>=0A=20=20</refsect1>=0Adiff=20--git=20=
a/src/bin/pg_upgrade/check.c=20b/src/bin/pg_upgrade/check.c=0Aindex=20=
dc060418e5..05a94087c5=20100644=0A---=20a/src/bin/pg_upgrade/check.c=0A=
+++=20b/src/bin/pg_upgrade/check.c=0A@@=20-316,8=20+316,13=20@@=20=
check_cluster_versions(void)=0A=20=09=20*=20upgrades=0A=20=09=20*/=0A=20=0A=
-=09if=20(GET_MAJOR_VERSION(old_cluster.major_version)=20<=20804)=0A-=09=09=
pg_fatal("This=20utility=20can=20only=20upgrade=20from=20PostgreSQL=20=
version=208.4=20and=20later.\n");=0A+=09/*=0A+=09=20*=20The=20minimum=20=
version=20supported=20then=20this=20code=20shipped=20in=20a=20major=20=
version=0A+=09=20*=20was=208.4.=20This=20has=20since=20been=20raised=20=
to=209.0,=20but=20the=20support=20code=20for=0A+=09=20*=20dealing=20with=20=
8.4=20remains=20to=20avoid=20refactoring=20in=20a=20backbranch.=0A+=09=20=
*/=0A+=09if=20(GET_MAJOR_VERSION(old_cluster.major_version)=20<=20900)=0A=
+=09=09pg_fatal("This=20utility=20can=20only=20upgrade=20from=20=
PostgreSQL=20version=209.0=20and=20later.\n");=0A=20=0A=20=09/*=20Only=20=
current=20PG=20version=20is=20supported=20as=20a=20target=20*/=0A=20=09=
if=20(GET_MAJOR_VERSION(new_cluster.major_version)=20!=3D=20=
GET_MAJOR_VERSION(PG_VERSION_NUM))=0A--=20=0A2.39.3=20(Apple=20Git-146)=0A=
=0A=

--Apple-Mail=_8E1F4B01-26B5-4AA5-91D7-740295A9FDB8--