Re: BUG #17774: Assert triggered on brin_minmax_multi.c

On Wed, Feb 8, 2023 at 11:05 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Dmitry Dolgov <9erthalion6(at)gmail(dot)com> writes:
> >> On Wed, Feb 08, 2023 at 10:03:01AM -0500, Tom Lane wrote:
> >> I'd believe this argument more readily if the calculation weren't being
> >> done in float arithmetic. Since it is, you're at the mercy of roundoff
> >> error ... and that small negative delta could certainly pass for
> >> roundoff error.
>
> > Hmm...yeah, good point. In both the reproducer I've posted and the
> > backtrace from the thread the delta is indeed rather small.
>
> I bet also it only fails when dealing with IPv6 addresses.
> With 32-bit IPv4 addresses, a float8 would have enough mantissa
> bits that the calculation wouldn't become imprecise.

Addresses from different families are treated as a distance of one, so I
don't think inserting a single IPv6 address would get this far, and in
fact I still get a crash in an empty table by taking out the IPv6 address
from Dmitry's example:

insert into brin_test values('127.0.0.1/0');
insert into brin_test values('0.0.0.0/12');

Adding some debug calls shows it starts off negative from the start:

=# insert into brin_test values('127.0.0.1/0');
INSERT 0 1
=# insert into brin_test values('0.0.0.0/12');
NOTICE: idx: 3 before div: -1.000000
NOTICE: idx: 3 after div: -0.003906
NOTICE: idx: 2 before div: -0.003906
NOTICE: idx: 2 after div: -0.000015
NOTICE: idx: 1 before div: -0.000015
NOTICE: idx: 1 after div: -0.000000
NOTICE: idx: 0 before div: -0.000000
NOTICE: idx: 0 after div: -0.000000

...so something else is wrong here but I haven't dug deeper yet.

--
John Naylor
EDB: http://www.enterprisedb.com