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
