Re: Crash in BRIN minmax-multi indexes - Mailing list pgsql-hackers

From Jaime Casanova
Subject Re: Crash in BRIN minmax-multi indexes
Date
Msg-id CAJKUy5iAN81-O8uyGpHw=XAR-n7bGJ+D-XbgtjPDnf+MEsO5UA@mail.gmail.com
Whole thread Raw
In response to Re: Crash in BRIN minmax-multi indexes  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: Crash in BRIN minmax-multi indexes  (Jaime Casanova <jcasanov@systemguards.com.ec>)
List pgsql-hackers
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.

-- 
Jaime Casanova
Director de Servicios Profesionales
SYSTEMGUARDS - Consultores de PostgreSQL



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Crash in BRIN minmax-multi indexes
Next
From: "'alvherre@alvh.no-ip.org'"
Date:
Subject: Re: libpq debug log