Thread

  1. Re: Crash in BRIN minmax-multi indexes

    Jaime Casanova <jcasanov@systemguards.com.ec> — 2022-10-04T04:26:56Z

    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