Re: [PATCH] Reject nonpositive Bloom filter element estimates - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: [PATCH] Reject nonpositive Bloom filter element estimates
Date
Msg-id aq1NgFiGcAtLPp6J@nathan
Whole thread
In response to [PATCH] Reject nonpositive Bloom filter element estimates  (CharSyam <charsyam@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Atsushi Ogawa
Date:
Subject: Re: [PATCH] Use Boyer-Moore-Horspool for simple LIKE contains patterns
Next
From: Álvaro Herrera
Date:
Subject: Re: Routed ON CONFLICT inserts broken by partition-local deferrable unique constraints in 19 and master