From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
Cc: | Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Crash in BRIN minmax-multi indexes |
Date: | 2022-10-03 17:53:34 |
Message-ID: | 3ef6a989-3c04-9d2b-3679-f3469952f7ba@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/29/22 08:53, Jaime Casanova wrote:
> ...
>
> Just found one more ocurrance of this one with this index while an
> autovacuum was running:
>
> """
> CREATE INDEX bt_f8_heap_seqno_idx
> ON public.bt_f8_heap
> USING brin (seqno float8_minmax_multi_ops);
> """
> Attached is a backtrace.
Thanks for the report!
I think I see the issue - brin_minmax_multi_union does not realize the
two summaries could have just one range each, and those can overlap so
that merge_overlapping_ranges combines them into a single one.
This is harmless, except that the assert int build_distances is overly
strict. Not sure if we should just remove the assert or only compute the
distances with (neranges>1).
Do you happen to have the core dump? It'd be useful to look at ranges_a
and ranges_b, to confirm this is indeed what's happening.
If not, how reproducible is it?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Chudnovsky | 2022-10-03 18:04:27 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
Previous Message | Matthias van de Meent | 2022-10-03 17:40:30 | Re: problems with making relfilenodes 56-bits |