public inbox for [email protected]
help / color / mirror / Atom feedFrom: Daniel Gustafsson <[email protected]>
To: Tom Lane <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Drouvot, Bertrand <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Noah Misch <[email protected]>
Cc: Jason Harvey <[email protected]>
Cc: Peter Geoghegan <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Tharakan, Robins <[email protected]>
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
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CALSof1GM6i21BLr8PsFiRYazakojvesdc+_MiR-L_V5NNkRuWg@mail.gmail.com>
<CAH2-Wz=9Cj8H0=GAiHducPETWf6ZXEzjk_pFkjPWnWH6hptpLA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
> On 5 Jul 2022, at 18:59, Tom Lane <[email protected]> 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
Attachments:
[application/octet-stream] 0001-Refuse-upgrades-from-pre-9.0-clusters.patch (2.2K, 2-0001-Refuse-upgrades-from-pre-9.0-clusters.patch)
download | inline diff:
From d0b747eb43980e4e639fd3844357e0ccbffbd705 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson <[email protected]>
Date: Thu, 16 May 2024 07:43:50 +0200
Subject: [PATCH] Refuse upgrades from pre-9.0 clusters
Commit 695b4a113ab added a dependency on retrieving oldestxid from
pg_control, which only exists in 9.0 and onwards, but the check for
8.4 as the oldest version was retained. Since there has been few if
any complaints of 8.4 upgrades not working, fix by setting 9.0 as
the oldest version supported rather than resurrecting 8.4 support.
Backpatch to all supported versions.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v12
---
doc/src/sgml/ref/pgupgrade.sgml | 2 +-
src/bin/pg_upgrade/check.c | 9 +++++++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index d401053edf..8add90e8ed 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -67,7 +67,7 @@ PostgreSQL documentation
</para>
<para>
- pg_upgrade supports upgrades from 8.4.X and later to the current
+ pg_upgrade supports upgrades from 9.0.X and later to the current
major release of <productname>PostgreSQL</productname>, including snapshot and beta releases.
</para>
</refsect1>
diff --git a/src/bin/pg_upgrade/check.c b/src/bin/pg_upgrade/check.c
index dc060418e5..05a94087c5 100644
--- a/src/bin/pg_upgrade/check.c
+++ b/src/bin/pg_upgrade/check.c
@@ -316,8 +316,13 @@ check_cluster_versions(void)
* upgrades
*/
- if (GET_MAJOR_VERSION(old_cluster.major_version) < 804)
- pg_fatal("This utility can only upgrade from PostgreSQL version 8.4 and later.\n");
+ /*
+ * The minimum version supported then this code shipped in a major version
+ * was 8.4. This has since been raised to 9.0, but the support code for
+ * dealing with 8.4 remains to avoid refactoring in a backbranch.
+ */
+ if (GET_MAJOR_VERSION(old_cluster.major_version) < 900)
+ pg_fatal("This utility can only upgrade from PostgreSQL version 9.0 and later.\n");
/* Only current PG version is supported as a target */
if (GET_MAJOR_VERSION(new_cluster.major_version) != GET_MAJOR_VERSION(PG_VERSION_NUM))
--
2.39.3 (Apple Git-146)
view thread (2+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox