Re: Crash in BRIN minmax-multi indexes

On 10/3/22 21:25, Jaime Casanova wrote:
> On Mon, Oct 03, 2022 at 07:53:34PM +0200, Tomas Vondra wrote:
>> 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.
>>
>
> I do have it.
>
> (gdb) p *ranges_a
> $4 = {
> typid = 701,
> colloid = 0,
> attno = 0,
> cmp = 0x0,
> nranges = 0,
> nsorted = 1,
> nvalues = 1,
> maxvalues = 32,
> target_maxvalues = 32,
> values = 0x55d2ea1987c8
> }
> (gdb) p *ranges_b
> $5 = {
> typid = 701,
> colloid = 0,
> attno = 0,
> cmp = 0x0,
> nranges = 0,
> nsorted = 1,
> nvalues = 1,
> maxvalues = 32,
> target_maxvalues = 32,
> values = 0x55d2ea196da8
> }
>

Thanks. That mostly confirms my theory. I'd bet that this

(gdb) p ranges_a->values[0]
(gdb) p ranges_b->values[0]

will print the same value. I've been able to reproduce this, but it's
pretty difficult to get the timing right (and it requires table with
just a single value in that BRIN range).

I'll get this fixed in a couple days. Considering the benign nature of
this issue (unnecessary assert) I'm not going to rush.

regards

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