From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
        pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17969: Assert failed in bloom_init() when
 false_positive_rate = 0.25
In-reply-to: <17969-a6c54de48026d694@postgresql.org>
References: <17969-a6c54de48026d694@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Sun, 11 Jun 2023 15:00:01 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <836411.1686502986.1@sss.pgh.pa.us>
Date: Sun, 11 Jun 2023 13:03:06 -0400
Message-ID: <836412.1686502986@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/836412.1686502986%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The following script:
> CREATE TABLE tbl (i int);
> CREATE INDEX idx ON tbl USING brin (i int4_bloom_ops(false_positive_rate =
> 0.25));
> INSERT INTO tbl VALUES(1);

> triggers an assertion failure:
> TRAP: failed Assert("(false_positive_rate >= BLOOM_MIN_FALSE_POSITIVE_RATE)
> && (false_positive_rate < BLOOM_MAX_FALSE_POSITIVE_RATE)"), File:
> "brin_bloom.c", Line: 282, PID: 1062784

> Reproduced starting from 77b88cd1b.

Hmph.  Surely that should read "false_positive_rate <=
BLOOM_MAX_FALSE_POSITIVE_RATE" ?

> Maybe that Assert is not needed at all...

Seems a little excessive to me too, given the comment near the #define
that the range limits are pretty arbitrary.  Perhaps what would be
suitable is "Assert(false_positive_rate > 0 && false_positive_rate < 1)"
to show that we don't need to check for failure of the subsequent log()
call, and that the log() must be negative so that the nbits result
will be sane.

			regards, tom lane