agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedpgsql: Check that oldestXID and oldestMulti are consistent at pg_upgrad
3+ messages / 2 participants
[nested] [flat]
* pgsql: Check that oldestXID and oldestMulti are consistent at pg_upgrad
@ 2026-09-18 21:32 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 3+ messages in thread
From: Heikki Linnakangas @ 2026-09-18 21:32 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/7b879c485243e61a0d4cb169717a8e96e9e875c2
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(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
* pgsql: Check that oldestXID and oldestMulti are consistent at pg_upgrad
@ 2026-09-18 21:32 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 1 reply; 3+ messages in thread
From: Heikki Linnakangas @ 2026-09-18 21:32 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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(-)
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgsql: Check that oldestXID and oldestMulti are consistent at pg_upgrad
@ 2026-09-19 15:02 Andrew Dunstan <andrew@dunslane.net>
parent: Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Dunstan @ 2026-09-19 15:02 UTC (permalink / raw)
To: Heikki Linnakangas <heikki.linnakangas@iki.fi>; pgsql-committers@lists.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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-09-19 15:02 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-09-18 21:32 pgsql: Check that oldestXID and oldestMulti are consistent at pg_upgrad Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-09-18 21:32 pgsql: Check that oldestXID and oldestMulti are consistent at pg_upgrad Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-09-19 15:02 ` Andrew Dunstan <andrew@dunslane.net>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox