On Thu, Aug 27, 2026 at 12:06 AM Chao Li <[email protected]> wrote: > > > > > On Aug 27, 2026, at 08:59, Masahiko Sawada <[email protected]> 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
