Re: Crash in BRIN minmax-multi indexes
| От | Tomas Vondra |
|---|---|
| Тема | Re: Crash in BRIN minmax-multi indexes |
| Дата | |
| Msg-id | 4db91321-1c6c-8527-912f-f6e4ef7b6821@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: Crash in BRIN minmax-multi indexes (Zhihong Yu <zyu@yugabyte.com>) |
| Ответы |
Re: Crash in BRIN minmax-multi indexes
Re: Crash in BRIN minmax-multi indexes |
| Список | pgsql-hackers |
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. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: