| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Check that oldestXID and oldestMulti are consistent at pg_upgrad |
| Date: | 2026-09-18 21:32:54 |
| Message-ID: | E1x7gCU-00000000JVJ-2Y9y@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
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(at)leadboat(dot)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(-)
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Heikki Linnakangas | 2026-09-18 19:15:02 | pgsql: Remove unused columns from pg_upgrade's query |