Re: [PATCH] Reject nonpositive Bloom filter element estimates

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: CharSyam <charsyam(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Reject nonpositive Bloom filter element estimates
Date: 2026-09-18 14:41:04
Message-ID: aq1NgFiGcAtLPp6J@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

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