Re: Crash in BRIN minmax-multi indexes

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Zhihong Yu <zyu(at)yugabyte(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Crash in BRIN minmax-multi indexes
Date: 2021-03-31 18:27:39
Message-ID: 1a0a7b9d-9bda-e3a2-7fa4-88f15042a051@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/31/21 8:20 PM, Zhihong Yu wrote:
> Hi,
> In build_distances():
>
>         a1 = eranges[i].maxval;
>         a2 = eranges[i + 1].minval;
>
> It seems there was overlap between the successive ranges, leading to
> delta = -6785000000
>

I've been unable to reproduce this, so far :-( How exactly did you
manage to reproduce it?

The thing is - how could there be an overlap? The way we build expanded
ranges that should not be possible, I think. Can you print the ranges at
the end of fill_expanded_ranges? That should shed some light on this.

FWIW I suspect those asserts on delta may be a bit problematic due to
rounding errors. And I found one issue in the inet distance function,
because apparently

test=# select '10.2.14.243/24'::inet < '10.2.14.231/24'::inet;
?column?
----------
f
(1 row)

but the delta formula currently ignores the mask. But that's a separate
issue.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-03-31 18:30:12 Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Previous Message Zhihong Yu 2021-03-31 18:20:20 Re: Crash in BRIN minmax-multi indexes