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
