On Wed, Mar 31, 2021 at 6:19 PM Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:
>
> On Wed, Mar 31, 2021 at 5:25 PM Tomas Vondra
> <tomas.vondra@enterprisedb.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