Re: pg_upgrade silently truncates nextMultiOffset to 32 bits

On 27/08/2026 10:06, Chao Li wrote:
>> On Aug 27, 2026, at 08:59, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>
>> Hi all,
>> (CCing Heikki as the committer of commit bd8d9c9bdfa)
>>
>> Commit bd8d9c9bdfa widened MultiXactOffset to uint64, but I found that
>> pg_upgrade still reads it as a uint32 value when reading the
>> pg_controldata continents:
>>
>> else if ((p = strstr(bufin, "Latest checkpoint's NextMultiOffset:")) != NULL)
>> {
>> :
>> p++; /* remove ':' char */
>> cluster->controldata.chkpnt_nxtmxoff = str2uint(p);
>>
>> I think it should use strtou64() instead. The attached 0001 patch
>> fixes it. It introduces str2uint64() as other fields are read by a
>> similar helper function str2uint().
>>
>> Also, when checking other similar codes around the new
>> MultiXactOffset, I found that pg_control_checkpoint() still reports
>> the value as an xid. I think we should report it as bigint instead.
>> What do you think? The attached 0002 patch fixes it.

Thanks, good catch!

> bigint is a signed int64, so it cannot represent the full uint64 range, although perhaps this is only a theoretical concern. If we want to avoid this limitation, should we use numeric instead?

xid8 seems like the most straightforward replacement. It's a little
bogus as a multixact offset it's not really an XID. But we were using
the 32-bit 'xid' type for it previously, it's in line with that.

I'll go do that. This requires bumping the catalog version, but since
we've bumped it already since 19beta3, that's OK.

- Heikki