From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Noah Misch <noah@leadboat.com>
To: orlovmg@gmail.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: 64-bit MultiXactOffset vs. 9.3->9.4 upgrade, pg_resetwal, "wraparound" msg
Date: Wed, 16 Sep 2026 14:33:34 +0300
Message-ID: <8fc26d4c-ff74-4cae-9c3d-db5c4f41d4ec@iki.fi> (raw)
In-Reply-To: <20260827231757.78.noahmisch@microsoft.com>
References: <20260827231757.78.noahmisch@microsoft.com>
On 28/08/2026 02:17, Noah Misch wrote:
> commit bd8d9c9 wrote:
>> Commit: Heikki Linnakangas <heikki.linnakangas@iki.fi>
>> CommitDate: Tue Dec 9 13:53:03 2025 +0200
>>
>> Widen MultiXactOffset to 64 bits
>
>> --- a/src/bin/pg_upgrade/pg_upgrade.c
>> +++ b/src/bin/pg_upgrade/pg_upgrade.c
>
>> + nxtmulti = old_cluster.controldata.chkpnt_nxtmulti;
>> + if (old_cluster.controldata.cat_ver >= MULTIXACT_FORMATCHANGE_CAT_VER)
>> + {
>> + /* Versions 9.3 - 18: convert all multixids */
>> + oldstMulti = old_cluster.controldata.chkpnt_oldstMulti;
>
> If a cluster's upgrade history includes an upgrade from 9.3 to early 9.4, it
> may have a wrong value here. Specifically, upgrades done before a61daa14
> (2014-07 commit) have that hazard. We still have backend code to detect such
> cases and reduce damage:
>
> ereport(LOG,
> (errmsg("cannot truncate up to MultiXact %u because it does not exist on disk, skipping truncation",
> newOldestMulti)));
>
> However, the pg_upgrade side from the v19 commit lacks such protection. If
> heap tuples still reference older multixacts than the faulty control data
> suggests, pg_upgrade will copy too small a range, making affected tuples
> unreadable.
Thanks, I'll look into this. My first reaction is that I think if
oldstMulti is incorrectly too old, the upgrade will fail because the
conversion routine will fail to find it. If it's too new, i.e. "in the
future", it will also fail to find it.
The third possibility is that the bogus oldstMulti value is within the
range of the "real" range. That can happen if multixid wraparound had
already happened before the (broken) 9.3 -> 9.4 upgrade. In that case,
even if the multixids are still readable on disk, you're one vacuum away
from truncating them. In other words, the damage has already been done,
or could be done at any minute. That's the scenario for which the commit
message 78db307bb2 says "this mechanism cannot save us".
But I'll do some testing of that. Let's ensure that the error message
makes sense at the very least.
> I also had Opus 4.8 look for defects in this change and write test cases. It
> didn't find the above problem, but it had other findings. I'm attaching the
> full report. I recommend fixing at least these before release:
>
>> +| 5 | `resetwal-nextmxoff-zero` | `src/bin/pg_resetwal/pg_resetwal.c:703`, and `-O` with no zero check at 297-307 | `pg_resetwal -f` (or `-O 0`) leaves `nextMultiOffset = 0`, the reserved "invalid offset"; first multixact created afterwards is permanently unreadable: `ERROR: MultiXact 1 has invalid offset` | Yes — `src/test/modules/test_slru/t/003_multixact_offset.pl` |
This was already fixed in commit 2cad308cb8.
>> +| 7 | `members-truncation-apparent-wraparound` | `src/backend/access/transam/multixact.c:2642-2647` | When `nextOffset` lands on a members page boundary, truncation logs `could not truncate directory "pg_multixact/members": apparent wraparound` (impossible for a 64-bit counter) and reclaims nothing | Yes — `003_multixact_offset.pl` |
Ok, I'll look into this one, and the other ones that might not be fixed yet.
- Heikki
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-hackers@postgresql.org
Cc: hlinnaka@iki.fi, noah@leadboat.com, orlovmg@gmail.com
Subject: Re: 64-bit MultiXactOffset vs. 9.3->9.4 upgrade, pg_resetwal, "wraparound" msg
In-Reply-To: <8fc26d4c-ff74-4cae-9c3d-db5c4f41d4ec@iki.fi>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox