Re: pg_upgrade silently truncates nextMultiOffset to 32 bits

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Subject: Re: pg_upgrade silently truncates nextMultiOffset to 32 bits
Date: 2026-08-27 08:20:06
Message-ID: d7308775-1f9a-4f3c-98e0-91a44d778e90@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-08-27 08:28:12 Re: Fix GRAPH TABLE label and property error reporting
Previous Message Gabriele Bartolini 2026-08-27 08:17:36 Re: Tracking role modification timestamps in pg_authid / pg_roles