Re: Crash in BRIN minmax-multi indexes

Поиск
Список
Период
Сортировка
От Zhihong Yu
Тема Re: Crash in BRIN minmax-multi indexes
Дата
Msg-id CALNJ-vQXKmcjesb1jmy=0xh3eLDY+xtqa4075WBEJ-9-f_ge-A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Crash in BRIN minmax-multi indexes  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: Crash in BRIN minmax-multi indexes
Список 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: Assertion failure with barriers in parallel hash join
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Crash in BRIN minmax-multi indexes