On 20/09/2026 05:12, Tom Lane wrote:
Noah Misch <[email protected]> writes:
On Fri, Sep 18, 2026 at 09:15:38PM +0300, Heikki Linnakangas wrote:
From 866999c1251fbbde2f1d9db2799734c7c6e8fe54 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <[email protected]>
Date: Fri, 18 Sep 2026 20:57:26 +0300
Subject: [PATCH 1/1] Check that oldestXID and oldestMulti are consistent at
pg_upgrade
I read this patch. It looks reasonable, and I expect it provides the intended
defense. Thank you.
The BF animals that run cross-version upgrade tests say that this
fails when upgrading from 9.2 [1]:
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database connection settings ok
Checking for unsupported encodings ok
Checking names of databases, roles, and tablespaces ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking oldestXID and oldestMultiXid consistency SQL command failed
SELECT datname, datfrozenxid, datminmxid FROM pg_catalog.pg_database
ERROR: column "datminmxid" does not exist
LINE 1: SELECT datname, datfrozenxid, datminmxid FROM pg_catalog.pg_...
^
Failure, exiting
Now, we've dropped support for upgrading from 9.2 in HEAD, but we
have not done so in v19, so I think this needs a fix in v19.
If nothing else works, we could just skip the whole check when source
server is <= 9.2.
Ugh, that's what I get for not actually testing with a real 9.2
installation..
Here's what I came up with for this. Thanks Andrew for also reporting
this off-list; this is essentially what you proposed too.
(I don't think this is worth breaking beta4 release freeze for, but
it should get fixed afterwards.)
I'm actually inclined to push this now, I don't see much risk of causing
more last-minute breakage. Isn't finding this kind of last-minute issues
exactly the reason we have the freeze? But that's just a weak opinion,
it also seems totally fine to me to leave this broken for beta4 and fix
later.
- Heikki
From c12c1d6c66514ae66fbe5436fcbb435e310bfda5 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <[email protected]>
Date: Sun, 20 Sep 2026 13:01:15 +0300
Subject: [PATCH 1/1] Fix pg_upgrade from version 9.2
Commit 7f25eccf41 added a cross-check between pg_database.datminmxid
and oldestMulti, but because PostgreSQL 9.2 doesn't have datminmxid,
it broke upgrade from version 9.2. Disable the check when upgrading
from 9.2 to fix.
This is for REL_19_STABLE only. Earlier versions don't have the check,
and on 'master' we no longer support upgrading from version 9.2.
Reported-by: Andrew Dunstan <[email protected]>
Discussion: https://www.postgresql.org/message-id/[email protected]
---
src/bin/pg_upgrade/check.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/bin/pg_upgrade/check.c b/src/bin/pg_upgrade/check.c
index 5b8c6ee145f..affc9e3c6cf 100644
--- a/src/bin/pg_upgrade/check.c
+++ b/src/bin/pg_upgrade/check.c
@@ -2758,6 +2758,15 @@ check_for_oldestxid_consistency(ClusterInfo *cluster)
int i_datfrozenxid;
int i_datminmxid;
+ /*
+ * Version 9.2 didn't have datminmxid. We could still cross-check
+ * datfrozenxid, but doesn't seem worth it since we're primarily worried
+ * about the rewriting of the multixact SLRUs losing data if the
+ * oldestMulti is set incorrectly.
+ */
+ if (GET_MAJOR_VERSION(old_cluster.major_version) < 903)
+ return;
+
prep_status("Checking oldestXID and oldestMultiXid consistency");
conn_template1 = connectToServer(cluster, "template1");
--
2.47.3
