Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: exclusion(at)gmail(dot)com, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25
Date: 2023-06-16 02:23:52
Message-ID: 2322240.1686882232@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> writes:
> It seems that the minimum false positive rate also doesn't work:

> postgres(1:3419179)=# create table t (a int);
> CREATE TABLE
> postgres(1:3419179)=# create index t_idx on t using brin (a
> int4_bloom_ops (false_positive_rate = 0.0001));
> CREATE INDEX
> postgres(1:3419179)=# insert into t values (1);
> 2023-06-16 11:14:01.349 JST [3419179] ERROR: the bloom filter is too
> large (8924 > 8144)
> 2023-06-16 11:14:01.349 JST [3419179] STATEMENT: insert into t values (1);
> ERROR: the bloom filter is too large (8924 > 8144)

Hmm, but it would work with a larger page size, right? If so
I'm disinclined to move the minimum. What I don't like about
the above is that the failure doesn't occur until you actually
insert an index entry. Is there a way to check for this at
CREATE INDEX time?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2023-06-16 05:29:41 Re: pg_dump assertion failure with "-n pg_catalog"
Previous Message Masahiko Sawada 2023-06-16 02:18:30 Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25