Date: Fri, 18 Sep 2026 09:41:04 -0500
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
Message-ID: <aq1NgFiGcAtLPp6J@nathan>
References: 
 <CAMrLSE671yN2u4zeo2pnUY2rm=arYfb0rVSr5v+9m9t9vL802w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAMrLSE671yN2u4zeo2pnUY2rm=arYfb0rVSr5v+9m9t9vL802w@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aq1NgFiGcAtLPp6J%40nathan>
Precedence: bulk

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