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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: shihao zhong <zhong950419(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: Re: BUG #17969: Assert failed in bloom_init() when false_positive_rate = 0.25
Date: 2023-11-08 05:18:33
Message-ID: ZUsaKYl9jKoATwRp@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Manika Singhal 2023-11-08 07:02:23 Re: BUG #18185: Error when calling whoami at the beginning of the installation
Previous Message Andrew Dunstan 2023-11-07 21:38:45 Re: BUG #18186: Question around integration