Re: Crash in BRIN minmax-multi indexes - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Crash in BRIN minmax-multi indexes
Date
Msg-id 3ef6a989-3c04-9d2b-3679-f3469952f7ba@enterprisedb.com
Whole thread Raw
In response to Re: Crash in BRIN minmax-multi indexes  (Jaime Casanova <jcasanov@systemguards.com.ec>)
Responses Re: Crash in BRIN minmax-multi indexes  (Jaime Casanova <jcasanov@systemguards.com.ec>)
List 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



pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: problems with making relfilenodes 56-bits
Next
From: Andrey Chudnovsky
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER