Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix
Date: 2021-02-12 21:00:00
Message-ID: 881ff073-daac-7946-cc66-c61dcfb5efa6@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello Tom,
12.02.2021 23:37, Tom Lane wrote:
> Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
>> I've found a division that produces NaN:
>> sel /= pow(FIXED_CHAR_SEL, fixed_prefix_len);
> Hmm. I'm not getting a NaN AFAICT, but I am getting pretty darn weird
> estimates. I agree this needs some kind of clamp.
>
> regression=# create table test (t text);
> CREATE TABLE
> regression=# explain SELECT * FROM test WHERE t ~* ('^' || repeat('-', 500));
> ...
> Seq Scan on test (cost=0.00..27.00 rows=10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104 width=32)
The same number I've seen on the master branch. But on REL_13_STABLE I
get a NaN and then the assertion failure. (I've chosen the version 13.2
in the bug report, but it's really delayed somewhere.)
Though that division produced a NaN for me on both branches.

Best regards,
Alexander

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-02-12 21:38:44 Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix
Previous Message Tom Lane 2021-02-12 20:37:41 Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix