Thread

Re: Crash in BRIN minmax-multi indexes

Jaime Casanova <jcasanov@systemguards.com.ec> — 2022-09-29T06:53:27Z

On Sun, Apr 04, 2021 at 07:52:50PM +0200, Tomas Vondra wrote:
> On 4/4/21 7:25 AM, Jaime Casanova wrote:
> > 
> > pgbench -i postgres
> > psql -c "CREATE INDEX ON pgbench_history USING brin (tid int4_minmax_multi_ops);" postgres
> > pgbench -c2 -j2 -T 300 -n postgres
> > 
> 
> Fixed and pushed too.
> 
> Turned out to be a silly bug in forgetting to remember the number of
> ranges after deduplication, which sometimes resulted in assert failure.
> It's a bit hard to trigger because concurrency / good timing is needed
> while summarizing the range, requiring a call to "union" function. Just
> running the pgbench did not trigger the issue for me, I had to manually
> call the brin_summarize_new_values().
> 
> For the record, I did a lot of testing with data randomized in various
> ways - the scripts are available here:
> 
> https://github.com/tvondra/brin-randomized-tests
> 
> It was focused on discovering issues in the distance functions, and
> comparing results with/without the index. Maybe the next step should be
> adding some changes to the data, which might trigger more issues like
> this one.
> 

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.

-- 
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL