Re: Crash in BRIN minmax-multi indexes

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;

Assert(delta >= 0);

On Wed, Mar 31, 2021 at 11:25 PM Jaime Casanova <
jcasanov(at)systemguards(dot)com(dot)ec> wrote:

> On Wed, Mar 31, 2021 at 6:19 PM Jaime Casanova
> <jcasanov(at)systemguards(dot)com(dot)ec> wrote:
> >
> > On Wed, Mar 31, 2021 at 5:25 PM Tomas Vondra
> > <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> > >
> > > Hi,
> > >
> > > I think I found the issue - it's kinda obvious, really. We need to
> > > consider the timezone, because the "time" parts alone may be sorted
> > > differently. The attached patch should fix this, and it also fixes a
> > > similar issue in the inet data type.
> > >
> >
> > ah! yeah! obvious... if you say so ;)
> >
> > > As for why the regression tests did not catch this, it's most likely
> > > because the data is likely generated in "nice" ordering, or something
> > > like that. I'll see if I can tweak the ordering to trigger these issues
> > > reliably, and I'll do a bit more randomized testing.
> > >
> > > There's also the question of rounding errors, which I think might cause
> > > random assert failures (but in practice it's harmless, in the worst
> case
> > > we'll merge the ranges a bit differently).
> > >
> > >
> >
> > I can confirm this fixes the crash in the query I showed and the
> original case.
> >
>
> But I found another, but similar issue.
>
> ```
> update public.brintest_multi set
> intervalcol = (select pg_catalog.avg(intervalcol) from
> public.brintest_bloom)
> ;
> ```
>
> BTW, i can reproduce just by executing "make installcheck" and
> immediately execute that query
>
> --
> Jaime Casanova
> Director de Servicios Profesionales
> SYSTEMGUARDS - Consultores de PostgreSQL
>