Re: Crash in BRIN minmax-multi indexes
От | Jaime Casanova |
---|---|
Тема | Re: Crash in BRIN minmax-multi indexes |
Дата | |
Msg-id | 20210404052550.GA4376@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 Thu, Apr 01, 2021 at 03:22:59PM +0200, Tomas Vondra wrote: > On 4/1/21 3:09 PM, Zhihong Yu wrote: > > Hi, > > Can you try this patch ? > > > > Thanks > > > > diff --git a/src/backend/access/brin/brin_minmax_multi.c > > b/src/backend/access/brin/brin_minmax_multi.c > > index 70109960e8..25d6d2e274 100644 > > --- a/src/backend/access/brin/brin_minmax_multi.c > > +++ b/src/backend/access/brin/brin_minmax_multi.c > > @@ -2161,7 +2161,7 @@ brin_minmax_multi_distance_interval(PG_FUNCTION_ARGS) > > delta = 24L * 3600L * delta; > > > > /* and add the time part */ > > - delta += result->time / (float8) 1000000.0; > > + delta += (result->time + result->zone * USECS_PER_SEC) / (float8) > > 1000000.0; > > > > That won't work, because Interval does not have a "zone" field, so this > won't even compile. > > The problem is that interval comparisons convert the value using 30 days > per month (see interval_cmp_value), but the formula in this function > uses 31. So either we can tweak that (seems to fix it for me), or maybe > just switch to interval_cmp_value directly. > Changing to using month of 30 days on the formula fixed it. 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 Attached a backtrace -- Jaime Casanova Director de Servicios Profesionales SystemGuards - Consultores de PostgreSQL
Вложения
В списке pgsql-hackers по дате отправления: