Re: Crash in BRIN minmax-multi indexes

On 4/4/21 7:25 AM, Jaime Casanova wrote:
> ...
> Changing to using month of 30 days on the formula fixed it.
> 

I've pushed fixes for all the bugs reported in this thread so far
(mostly distance calculations, ...), and one bug (swapped operator
parameters in one place) I discovered while working on the fixes.

> and I found another issue, this time involves autovacuum which makes it
> a little more complicated to reproduce.
> 
> Currently the only stable way to reproduce it is using pgbench:
> 
> 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.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company