Re: Crash in BRIN minmax-multi indexes

Zhihong Yu <zyu@yugabyte.com>

From: Zhihong Yu <zyu@yugabyte.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Jaime Casanova <jcasanov@systemguards.com.ec>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-01T13:31:31Z
Lists: 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
>

Commits

  1. Fix assert in BRIN build_distances

  2. Fix bug in brin_minmax_multi_union

  3. Fix order of parameters in BRIN minmax-multi calls

  4. Fix BRIN minmax-multi distance for inet type

  5. Fix BRIN minmax-multi distance for timetz type

  6. Fix BRIN minmax-multi distance for interval type