Re: Crash in BRIN minmax-multi indexes

Zhihong Yu <zyu@yugabyte.com>

From: Zhihong Yu <zyu@yugabyte.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Jaime Casanova <jcasanov@systemguards.com.ec>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-31T22:53:45Z
Lists: pgsql-hackers
Hi,
For inet data type fix:

+       unsigned char a = addra[i];
+       unsigned char b = addrb[i];
+
+       if (i >= lena)
+           a = 0;
+
+       if (i >= lenb)
+           b = 0;

Should the length check precede the addra[i] ?
Something like:

       unsigned char a;
       if (i >= lena) a = 0;
       else a = addra[i];

Cheers

On Wed, Mar 31, 2021 at 3: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.
>
> 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).
>
>
> regards
>
> --
> Tomas Vondra
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Commits

  1. Fix assert in BRIN build_distances

  2. Fix bug in brin_minmax_multi_union

  3. Fix order of parameters in BRIN minmax-multi calls

  4. Fix BRIN minmax-multi distance for inet type

  5. Fix BRIN minmax-multi distance for timetz type

  6. Fix BRIN minmax-multi distance for interval type