On Mon, Oct 03, 2022 at 10:29:38PM +0200, Tomas Vondra wrote:
> 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.
>
you're right, they are same value
(gdb) p ranges_a->values[0]
$1 = 4679532294229561068
(gdb) p ranges_b->values[0]
$2 = 4679532294229561068
--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL
