Re: 64-bit MultiXactOffset vs. 9.3->9.4 upgrade, pg_resetwal, "wraparound" msg

Noah Misch <noah(at)leadboat(dot)com> 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 <heikki(dot)linnakangas(at)iki(dot)fi>
>> 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.

(I don't think this is worth breaking beta4 release freeze for, but
it should get fixed afterwards.)

regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=crake&dt=2026-09-19%2014%3A17%3A23