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