agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedFrom: Andrew Dunstan <andrew@dunslane.net>
To: Heikki Linnakangas <heikki.linnakangas@iki.fi>
To: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Check that oldestXID and oldestMulti are consistent at pg_upgrad
Date: Sat, 19 Sep 2026 11:02:09 -0400
Message-ID: <baef33d6-0416-48db-8e4d-0529a10a101a@dunslane.net> (raw)
In-Reply-To: <E1x7gCU-00000000JVL-2dJ6@gemulon.postgresql.org>
References: <E1x7gCU-00000000JVL-2dJ6@gemulon.postgresql.org>
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
view thread (3+ messages)
Message-ID: <baef33d6-0416-48db-8e4d-0529a10a101a@dunslane.net>
Permalink: ../baef33d6-0416-48db-8e4d-0529a10a101a@dunslane.net/
Also on: postgresql.org/message-id/baef33d6-0416-48db-8e4d-0529a10a101a@dunslane.net
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: andrew@dunslane.net, heikki.linnakangas@iki.fi, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Check that oldestXID and oldestMulti are consistent at pg_upgrad
In-Reply-To: <baef33d6-0416-48db-8e4d-0529a10a101a@dunslane.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox