Re: Crash in BRIN minmax-multi indexes
Jaime Casanova <jcasanov@systemguards.com.ec>
From: Jaime Casanova <jcasanov@systemguards.com.ec>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Zhihong Yu <zyu@yugabyte.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-09-29T06:53:27Z
Lists: pgsql-hackers
Attachments
- crash_brin_max_multi_float8.txt (text/plain)
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