| From: | Postgress Cybrosys <postgress(at)cybrosys(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Fix type of 'reduction' variable in _bt_singleval_fillfactor() |
| Date: | 2026-03-19 05:57:31 |
| Message-ID: | CAG+=MFWUyr3pjHk32z6LqiTmULw_1cuje7c8bnQnd+nKPRM54Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
While reviewing nbtdedup.c I noticed a minor type mismatch in
_bt_singleval_fillfactor(). The local variable 'reduction' is declared
as 'int', but it holds the result of multiplying 'leftfree' (which is
type Size, i.e. size_t / unsigned long) by a double factor, and is
then subtracted from state->maxpostingsize, which is also Size.
Using a signed int here is semantically incorrect: Size is the
appropriate type for any variable representing a byte count, and
it matches the type of every other variable involved in this
calculation.
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. 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.
The fix is a one-line change: declare 'reduction' as Size instead
of int.
A patch file is attached.
Thanks & Regards,
*Jhon k*
Postgres Specialist
Project & IT Department
Cybrosys Technologies
Mobile
postgress(at)cybrosys(dot)com
+91 8606827707
+91 8606827707
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Fix-type-of-reduction-variable-in-_bt_singleval_fill.patch | text/x-patch | 1.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | 2026-03-19 06:38:04 | RE: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication | |
| Previous Message | Peter Eisentraut | 2026-03-19 05:57:29 | Re: Supporting non-deterministic collations with tailoring rules. |