public inbox for [email protected]
help / color / mirror / Atom feedRe: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load
2+ messages / 2 participants
[nested] [flat]
* Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load
@ 2024-05-16 06:11 Daniel Gustafsson <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Daniel Gustafsson @ 2024-05-16 06:11 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Drouvot, Bertrand <[email protected]>; Andres Freund <[email protected]>; Justin Pryzby <[email protected]>; Noah Misch <[email protected]>; Jason Harvey <[email protected]>; Peter Geoghegan <[email protected]>; PostgreSQL Hackers <[email protected]>; Tharakan, Robins <[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)
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load
@ 2024-05-16 17:47 Tom Lane <[email protected]>
parent: Daniel Gustafsson <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2024-05-16 17:47 UTC (permalink / raw)
To: Daniel Gustafsson <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Drouvot, Bertrand <[email protected]>; Andres Freund <[email protected]>; Justin Pryzby <[email protected]>; Noah Misch <[email protected]>; Jason Harvey <[email protected]>; Peter Geoghegan <[email protected]>; PostgreSQL Hackers <[email protected]>; Tharakan, Robins <[email protected]>
Daniel Gustafsson <[email protected]> writes:
>> 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.
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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-05-16 17:47 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-05-16 06:11 Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load Daniel Gustafsson <[email protected]>
2024-05-16 17:47 ` Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox