Re: Fix type of 'reduction' variable in _bt_singleval_fillfactor()

On Thu, Mar 19, 2026 at 1:57 AM Postgress Cybrosys
<postgress(at)cybrosys(dot)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 -= 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?

--
Peter Geoghegan