Message-ID: <baef33d6-0416-48db-8e4d-0529a10a101a@dunslane.net>
Date: Sat, 19 Sep 2026 11:02:09 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pgsql: Check that oldestXID and oldestMulti are consistent at
 pg_upgrad
To: Heikki Linnakangas <heikki.linnakangas@iki.fi>,
 pgsql-committers@lists.postgresql.org
References: <E1x7gCU-00000000JVL-2dJ6@gemulon.postgresql.org>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
In-Reply-To: <E1x7gCU-00000000JVL-2dJ6@gemulon.postgresql.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/baef33d6-0416-48db-8e4d-0529a10a101a%40dunslane.net>
Precedence: bulk


On 2026-09-18 Fr 5:32 PM, Heikki Linnakangas wrote:
> Check that oldestXID and oldestMulti are consistent at pg_upgrade
>
> Now that pg_upgrade will rewrite multixid members, starting from
> oldestMulti, it's important that oldestMulti is valid.  Add a sanity
> check that oldestMulti is not newer than the oldest datminmxid value
> in pg_database.
>
> One case where this could happen is if the cluster was previously
> upgraded to version 9.3 with a buggy pg_upgrade version that didn't
> have commit a61daa14d5.  This new pg_upgrade check is similar to the
> defence that was added in commit 78db307bb2 to VACUUM to avoid
> truncating away multixids if oldestMulti is too new.  This pg_upgrade
> check differs in that we don't try to soldier on with the upgrade if
> the oldestMultiXID is inconsistent, but rather just abort the upgrade.
>
> Reported-by: Noah Misch <noah@leadboat.com>
> Discussion: https://www.postgresql.org/message-id/20260827231757.78.noahmisch@microsoft.com
> Backpatch-through: 19
>
> Branch
> ------
> REL_19_STABLE
>
> Details
> -------
> https://git.postgresql.org/pg/commitdiff/5cd84ed6274ecd552f2991c54710608c0ef4cdc7
>
> Modified Files
> --------------
> src/backend/access/transam/multixact.c | 28 --------------
> src/bin/pg_upgrade/check.c             | 71 ++++++++++++++++++++++++++++++++++
> src/include/access/multixact.h         | 31 +++++++++++++--
> 3 files changed, 99 insertions(+), 31 deletions(-)


This has broken upgrade from release 9.2 still supposedly supported in 
release 19 (but not 20, for which the minimum will be 10). The log 
complains that datminmxid doesn't exist. Since we didn't have multixids 
until 9.3 could we just skip this check if upgrading from 9.2?


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com