On Thu, Apr 01, 2021 at 03:22:59PM +0200, Tomas Vondra 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.
>
Changing to using month of 30 days on the formula fixed it.
and I found another issue, this time involves autovacuum which makes it
a little more complicated to reproduce.
Currently the only stable way to reproduce it is using pgbench:
pgbench -i postgres
psql -c "CREATE INDEX ON pgbench_history USING brin (tid int4_minmax_multi_ops);" postgres
pgbench -c2 -j2 -T 300 -n postgres
Attached a backtrace
--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL
