| 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: | Whole Thread | Raw Message | 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 |