From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Zhihong Yu <zyu(at)yugabyte(dot)com>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Crash in BRIN minmax-multi indexes |
Date: | 2021-04-01 13:22:59 |
Message-ID: | 4db91321-1c6c-8527-912f-f6e4ef7b6821@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Zhihong Yu | 2021-04-01 13:31:31 | Re: Crash in BRIN minmax-multi indexes |
Previous Message | Robert Haas | 2021-04-01 13:14:34 | Re: New IndexAM API controlling index vacuum strategies |