Re: Crash in BRIN minmax-multi indexes
От | Jaime Casanova |
---|---|
Тема | Re: Crash in BRIN minmax-multi indexes |
Дата | |
Msg-id | YzVA55qS0hgz8P3r@ahch-to обсуждение исходный текст |
Ответ на | Re: Crash in BRIN minmax-multi indexes (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: Crash in BRIN minmax-multi indexes
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: