MIME-Version: 1.0
References: 
 <CAG+=MFWUyr3pjHk32z6LqiTmULw_1cuje7c8bnQnd+nKPRM54Q@mail.gmail.com>
In-Reply-To: 
 <CAG+=MFWUyr3pjHk32z6LqiTmULw_1cuje7c8bnQnd+nKPRM54Q@mail.gmail.com>
From: Peter Geoghegan <pg@bowt.ie>
Date: Thu, 19 Mar 2026 18:09:07 -0400
Message-ID: 
 <CAH2-Wz=KCRgu=8Wh3L7OW1dwHr3QzDJNff4B2gi2JG3Gz0p-+g@mail.gmail.com>
Subject: Re: Fix type of 'reduction' variable in _bt_singleval_fillfactor()
To: Postgress Cybrosys <postgress@cybrosys.com>
Cc: pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAH2-Wz%3DKCRgu%3D8Wh3L7OW1dwHr3QzDJNff4B2gi2JG3Gz0p-%2Bg%40mail.gmail.com>
Precedence: bulk

On Thu, Mar 19, 2026 at 1:57=E2=80=AFAM Postgress Cybrosys
<postgress@cybrosys.com> wrote:
> While no overflow occurs with current BLCKSZ limits (the product is
> at most ~30KB on a standard build, well within INT_MAX), the type
> mismatch could silently produce incorrect behaviour on non-standard
> builds compiled with a very large BLCKSZ.

We don't support BLCKSZ greater than 32KiB. Fields like
ItemIdData.lp_len only have space for 15 bits (independent of BLCKSZ
itself). Many places (likely thousands) rely on that limit.

> In that case, if the
> product exceeded INT_MAX, 'reduction' would wrap to a large negative
> number. The subsequent check:
>
>     if (state->maxpostingsize > reduction)
>         state->maxpostingsize -=3D reduction;
>
> would then subtract a negative value, i.e. increase maxpostingsize
> instead of reducing it, silently defeating the single-value fill
> strategy entirely.

This cannot happen with any supported BLCKSZ. Even if we wanted to
support larger BLCKSZ builds, why start here?

--=20
Peter Geoghegan