Re: pg_upgrade silently truncates nextMultiOffset to 32 bits

On Thu, Aug 27, 2026 at 12:06 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> 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.
>
> 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.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com