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

From Heikki Linnakangas
Subject Re: 64-bit MultiXactOffset vs. 9.3->9.4 upgrade, pg_resetwal, "wraparound" msg
Date
Msg-id 5f772c36-a1c6-497e-8cba-a2c4ade7c725@iki.fi
Whole thread
In response to Re: 64-bit MultiXactOffset vs. 9.3->9.4 upgrade, pg_resetwal, "wraparound" msg  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 64-bit MultiXactOffset vs. 9.3->9.4 upgrade, pg_resetwal, "wraparound" msg
List pgsql-hackers
On 20/09/2026 05:12, Tom Lane wrote:
> Noah Misch <noah@leadboat.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.linnakangas@iki.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.

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

Attachment

pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Add a Nix flake
Next
From: "ZizhuanLiu X-MAN"
Date:
Subject: Re: Optimize MCV stats for sortable types and utilize sorted-order properties