On Thu, Mar 19, 2026 at 1:57 AM Postgress Cybrosys <[email protected]> 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
