Re: Crash in BRIN minmax-multi indexes - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: Crash in BRIN minmax-multi indexes
Date
Msg-id CALNJ-vQ7YWQF_t1Bjf1OGLh5qEPsYxKckda7aJnR_3Njba-SwQ@mail.gmail.com
Whole thread Raw
In response to Re: Crash in BRIN minmax-multi indexes  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
Hi, Tomas:
Thanks for the correction.

I think switching to interval_cmp_value() would be better (with a comment explaining why).

Cheers

On Thu, Apr 1, 2021 at 6:23 AM Tomas Vondra <tomas.vondra@enterprisedb.com> 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.

regards

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

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Crash in BRIN minmax-multi indexes
Next
From: Masahiko Sawada
Date:
Subject: Re: Flaky vacuum truncate test in reloptions.sql