Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25 - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25
Date
Msg-id ZUsaKYl9jKoATwRp@paquier.xyz
Whole thread Raw
In response to Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-bugs
On Tue, Oct 24, 2023 at 04:00:00PM +0300, Alexander Lakhin wrote:
> I had started this discussion with the same question, but Tom Lane proposed
> to reformulate the Assert [1] and I agree that it's for good.
> Index attribute options are checked when an index created, but then
> attoptions can be changed in pg_attribute, for example. I mean that such
> a check makes sense because there is an intermediate level between setting
> the option and using it.

This was registered in the CF, so I've looked at what you have here.
As an expected percentage, enlarging the check as suggested is OK by
me, so I've applied and backpatched the change.

It's indeed surprising that we would check that on the first insert
rather than enforcing a check at index creation because we know that
it would be incompatible, but we cannot cross-check that in the
individual reloption parsing, which is what is used when defining an
index.  This could be achieved with a post-parsing callback triggered
once all the options are parsed and individually validated, at least
it would be cleaner.  Not backpatchable, but enforceable even if an
index build is skipped.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: BUG #18186: Question around integration
Next
From: Manika Singhal
Date:
Subject: Re: BUG #18185: Error when calling whoami at the beginning of the installation