From: Nathan Bossart <nathandbossart@gmail.com>
To: CharSyam <charsyam@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] Reject nonpositive Bloom filter element estimates
Date: Fri, 18 Sep 2026 09:41:04 -0500
Message-ID: <aq1NgFiGcAtLPp6J@nathan> (raw)
In-Reply-To: <CAMrLSE671yN2u4zeo2pnUY2rm=arYfb0rVSr5v+9m9t9vL802w@mail.gmail.com>
References: <CAMrLSE671yN2u4zeo2pnUY2rm=arYfb0rVSr5v+9m9t9vL802w@mail.gmail.com>
On Fri, Sep 18, 2026 at 07:31:04PM +0900, CharSyam wrote:
> bloom_create() currently accepts a zero total_elems estimate. This
> causes optimal_k() to divide by zero and then convert infinity to int,
> which is undefined behavior.
>
> The attached patch rejects nonpositive estimates before the calculation.
For backend functions like this, I don't see much value in checking the
arguments like this. It seems highly unlikely that any caller will provide
a total_elems setting of 0. Maybe an assertion would be more appropriate,
but IMHO we can still do without it.
> It also performs the bitset size multiplication as unsigned arithmetic
> to avoid signed overflow for very large positive estimates, and adds a
> regression test for the zero case.
Again, it seems highly unlikely that any caller will provide a total_elems
value even close to 4.6 quintillion.
--
nathan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, charsyam@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Reject nonpositive Bloom filter element estimates
In-Reply-To: <aq1NgFiGcAtLPp6J@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox