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
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 |