Re: pg_upgrade silently truncates nextMultiOffset to 32 bits

On 27/08/2026 11:20, Heikki Linnakangas wrote:
> Sorry, I missed this reply of yours earlier.
>
> On 27/08/2026 10:35, Masahiko Sawada wrote:
>> On Thu, Aug 27, 2026 at 12:06 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>>> 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?
>>
>> I'd prefer to keep bigint here. pg_get_multixact_stats() already
>> reports num_members and members_size as int8, and both are derived
>> from these same offsets. Also, other fields in pg_control_checkpoint()
>> are fixed-width types, whereas numeric is pass-by-reference.
>>
>> I considered using xid8 instead but it has only comparison operators
>> and no arithmetic, so we couldn't compute a delta between two
>> checkpoints.
>
> Hmm, that's a good point, although 'xid' didn't have those operators or
> arithmetic either.

That was inaccurate: both 'xid' and 'xid8' do have comparison operators.
But they don't have a "minus" or "diff" operator, so you indeed cannot
easily do "b - a".

I don't have a strong opinion, I'm happy with either bigint or xid8
here. Bigint is probably more convenient in practice, and it's good to
not confuse mxact offsets with transaction ids by abusing the xid8 type.
Then again, it was 'xid' before, which had the same issues and we went
with 'xid' anyway. Then again, now that it doesn't wrap around anymore,
maybe 'bigint' makes more sense now.

Would you like to decide and commit this, or would you prefer me to do it?

- Heikki