Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w36OC-000tui-1Y for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Mar 2026 05:57:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w36OB-00Gh6L-1I for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Mar 2026 05:57:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w36OA-00GgvE-2l for pgsql-hackers@lists.postgresql.org; Thu, 19 Mar 2026 05:57:47 +0000 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w36O7-00000000UAD-07Mm for pgsql-hackers@postgresql.org; Thu, 19 Mar 2026 05:57:45 +0000 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-660dcafc85aso1263943a12.0 for ; Wed, 18 Mar 2026 22:57:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773899863; cv=none; d=google.com; s=arc-20240605; b=NCReYpfEXLR+TTC7y7S7cj60ZAEy8751jjq6G7cQEfCO/TYKyzEiRkX6JtVHf2uUJV zf/XiMwEsWGN2wj9VGwN2Ti/UHq9WFmhS2sj0FVnRI/R0mGn1vqlnxQCB4BYKHYERKQp s2BpavfJbka/kgIlzGq/oe2zoGDEClVErUoATSHV+SPEGlh91y6vyTZMWG378rsDwZeB cyVD5iAEq8g6tGux41o0QzXbjx9UdCQPNzT+gOxgo8884WDrbaXdAgZ7+sbIoAxy3QLj SOgzGVhRBhujb8a6hgFTT2kkYuB+NC7a0vO6mZpeAAjnVXPKgpXDFRAaClRSdqRHhnj6 /8ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=dGYxK/kFl3q2I0qqWWs8zIuYEcGlCmBE281ra4GCHKw=; fh=33OU7BWuulPFH378PdKTnpeW+jw3IP20DTmpLDeQ3pE=; b=iUxcjyOQlSmZIvPowASfhXfJK1hZhiGuPhAbnEV3MExSN5m4nT7WXeznOws8p01lKk y3lU3qxbTi4EixqByrDCTSzoOHyv65WFCKby87seW5jngjTIJJl8md0YVr1wd6P/bTKT mtDJr5MKZ71dpNkWvF8fKG/Odhp4Vq2dw+uVOXYCGn+rN9tnL2HtJtXqyoCu3z/VS9hp ryU3FOLa2I0UgcrO3Wpz5jt6cWUbK5vWdKJT7QqVbUUVp3GW3fak+Jb3pz6w4avu5g2e BvTKDHHavafc6wth6wQZXKnq6JwXF5QjVq5fSl66PqXV4YGrTR3OUCGMWTIeFUTeFft4 smHg==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybrosys-com.20230601.gappssmtp.com; s=20230601; t=1773899863; x=1774504663; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=dGYxK/kFl3q2I0qqWWs8zIuYEcGlCmBE281ra4GCHKw=; b=JlITGCkm4vGMtGTCHBbrymbm11aBWhrpsOgidvUqdsMzuHde0Ol2302xQpf/cIDn1j f4Fh4JuIIMzIWJWRNhl0Cw8lpyMbALFg0dlYwI4Rh2oaQZrIz0TuokV0dGBh1O5vPqa5 IezVmi5TJcALg25oQ/O1/28zIPeVomCGZYOZRPWh4bg1m0HOV4LN1N0XdwD6lvrWChPn aH1C+eSBvp4iJmJIoG5reGdrQ6VNML0y7AmIYx2DgMRmjbmrNQvHSNhDqxo9M9SaKm4c GUFrttVVbj6861bCGc2yGm0xvt3BrSIJBxycJ3OGCnaWNkblb/f8dOqrLv9bZMcppOF4 gw7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773899863; x=1774504663; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dGYxK/kFl3q2I0qqWWs8zIuYEcGlCmBE281ra4GCHKw=; b=VWo+bs1mZEExWvikOx5E3mrelF7mExmUoT8ThHhpxi2FPPZWvS6Ps5+oB3FTrRVCHn u2j70oeFKeIz5cLAUFStWSkPFzvkmotgZcWrNmMIXbLvKH2Ag4ia+MtrkqHbq44yDBUJ KS5QA1Y1e2eF6EBmlupezRYjYz07vZcql75ueQh2jJSPZMmtFy32SfojUdRZB4dPrv16 82QmzS2uHuecdih1lVkWM2YLxtOlYxXq6vXEx9gCfXa0PnnWKTmxhYFlUjijUQL6Caqj +tbVA48TMNyz8vkQJ+ViKIudA3qERATZhXXWubqsvQgvdDKfWdwJ6z2SVTPecVgVGnvk 15Ww== X-Gm-Message-State: AOJu0YzGLoLe1EBVwhhfJW+YKXol5+qZbdlJuNBeSNHm8+yb7EcNMmjx GQayZk9CAxhVjse4nkesOuf/VqtrXoab3xleRvDVhJaUKVum0V/Gi3Lb+Cdqc7g83SF0nGtGski EqyR0Kfg8H0BpMobB4KpBeP6/mv+kVzItly3qcPPYbzOIpO6CJqO3tklJxhTC X-Gm-Gg: ATEYQzxm8o7jcc7K3q929W299N43IQ+PydOHmpCPNEm4kFDD3tbXniQluKhaBTciGIA 9+abwaZfHmgYmiK+g4VfWyn9oeKFmnDOsAxM+Sju6lZGVbmwC6id5nwHCLkFLuE8ry38NxoEwVe pZEXsrMIlg+v8kRigGgdzCWBmIpo6WnlwUS5nIjV8uEhlEtUz9l8klRigsKfzYtBIq8ienfQIn1 RekoYA4m9MNedeFSWLI4Q+0PGSc0V94KGHHfZwHqV7NBueVmqFDWA+3dkCboECS+jNfVw== X-Received: by 2002:a05:6402:5111:b0:667:7fcb:3a2c with SMTP id 4fb4d7f45d1cf-667b33ebdcdmr3702195a12.24.1773899862691; Wed, 18 Mar 2026 22:57:42 -0700 (PDT) MIME-Version: 1.0 From: Postgress Cybrosys Date: Thu, 19 Mar 2026 11:27:31 +0530 X-Gm-Features: AaiRm52fMbfndo0fU6utQU01ljMuuSSmytllmTOy87P5-PvqJnTHvsC32eEvwyk Message-ID: Subject: Fix type of 'reduction' variable in _bt_singleval_fillfactor() To: pgsql-hackers@postgresql.org Content-Type: multipart/mixed; boundary="0000000000002f11d9064d5a3fb0" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002f11d9064d5a3fb0 Content-Type: multipart/alternative; boundary="0000000000002f11d9064d5a3fae" --0000000000002f11d9064d5a3fae Content-Type: text/plain; charset="UTF-8" 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 Mail Mobile WhatsApp postgress@cybrosys.com +91 8606827707 +91 8606827707 --0000000000002f11d9064d5a3fae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

While reviewing nbtdedup.c I noticed a min= or 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 / unsign= ed long) by a double factor, and is
then subtracted from state->maxpo= stingsize, which is also Size.

Using a signed int here is semantical= ly 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 I= NT_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:

=C2=A0 =C2=A0 if (state-&= gt;maxpostingsize > reduction)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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.

The fix is a one-line c= hange: declare 'reduction' as Size instead
of int.

A patc= h file is attached.

Thanks & Regards,=

Jhon k

Postgres Specialist
=

Project &am= p; IT Department

Cybrosys Technologies


Mail

Mobile

WhatsApp


postgress@cybrosys.com

+91 8606827707

+91 8606827707


=
--0000000000002f11d9064d5a3fae-- --0000000000002f11d9064d5a3fb0 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Fix-type-of-reduction-variable-in-_bt_singleval_fill.patch" Content-Disposition: attachment; filename="0001-Fix-type-of-reduction-variable-in-_bt_singleval_fill.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mmx25uk20 RnJvbSBiNjc5NzgwOWEyMmY0NDg0MWNhMTdmM2JiNzUwYjcxNTQ1ODE4NjcwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBDeWJyb3N5cyA8cG9zdGdyZXNzQGN5YnJvc3lzLmNvbT4KRGF0 ZTogVGh1LCAxOSBNYXIgMjAyNiAxMToyMjowOCArMDUzMApTdWJqZWN0OiBbUEFUQ0hdIEZpeCB0 eXBlIG9mIHJlZHVjdGlvbiB2YXJpYWJsZSBpbiBfYnRfc2luZ2xldmFsX2ZpbGxmYWN0b3IKClRo ZSBsb2NhbCB2YXJpYWJsZSAncmVkdWN0aW9uJyBpbiBfYnRfc2luZ2xldmFsX2ZpbGxmYWN0b3Io KSB3YXMKZGVjbGFyZWQgYXMgaW50LCBidXQgaXQgaG9sZHMgdGhlIHJlc3VsdCBvZiBtdWx0aXBs eWluZyBsZWZ0ZnJlZQood2hpY2ggaXMgU2l6ZSwgaS5lLiBzaXplX3QgLyB1bnNpZ25lZCBsb25n KSBieSBhIGRvdWJsZSBmYWN0b3IuCgpVc2luZyBhIHNpZ25lZCBpbnQgaXMgYSB0eXBlIG1pc21h dGNoOiBTaXplIGlzIHRoZSBjb3JyZWN0IHR5cGUgZm9yCmFueSBxdWFudGl0eSByZXByZXNlbnRp bmcgYSBieXRlIGNvdW50LCBhbmQgbWF0Y2hlcyB0aGUgdHlwZSBvZiB0aGUKdmFyaWFibGUgaXQg aXMgc3VidHJhY3RlZCBmcm9tIChtYXhwb3N0aW5nc2l6ZSkuCgpJbiBwcmFjdGljZSBubyBvdmVy ZmxvdyBvY2N1cnMgd2l0aCBjdXJyZW50IEJMQ0tTWiBsaW1pdHMsIGJ1dCB0aGUKd3JvbmcgdHlw ZSBpcyBtaXNsZWFkaW5nIGFuZCBjb3VsZCBzaWxlbnRseSBtaXNiZWhhdmUgb24gbm9uLXN0YW5k YXJkCmJ1aWxkcyB3aXRoIHZlcnkgbGFyZ2UgQkxDS1NaIHZhbHVlcy4KLS0tCiBzcmMvYmFja2Vu ZC9hY2Nlc3MvbmJ0cmVlL25idGRlZHVwLmMgfCAyICstCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNl cnRpb24oKyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9hY2Nlc3Mv bmJ0cmVlL25idGRlZHVwLmMgYi9zcmMvYmFja2VuZC9hY2Nlc3MvbmJ0cmVlL25idGRlZHVwLmMK aW5kZXggMDg4ODQxMTZhZWMuLjYxYmY4NzdkNWQ5IDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC9h Y2Nlc3MvbmJ0cmVlL25idGRlZHVwLmMKKysrIGIvc3JjL2JhY2tlbmQvYWNjZXNzL25idHJlZS9u YnRkZWR1cC5jCkBAIC04MjIsNyArODIyLDcgQEAgc3RhdGljIHZvaWQKIF9idF9zaW5nbGV2YWxf ZmlsbGZhY3RvcihQYWdlIHBhZ2UsIEJURGVkdXBTdGF0ZSBzdGF0ZSwgU2l6ZSBuZXdpdGVtc3op CiB7CiAJU2l6ZQkJbGVmdGZyZWU7Ci0JaW50CQkJcmVkdWN0aW9uOworCVNpemUJCXJlZHVjdGlv bjsKIAogCS8qIFRoaXMgY2FsY3VsYXRpb24gbmVlZHMgdG8gbWF0Y2ggbmJ0c3BsaXRsb2MuYyAq LwogCWxlZnRmcmVlID0gUGFnZUdldFBhZ2VTaXplKHBhZ2UpIC0gU2l6ZU9mUGFnZUhlYWRlckRh dGEgLQotLSAKMi4zNC4xCgo= --0000000000002f11d9064d5a3fb0--