Re: [HACKERS] Multi column range partition table

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: [HACKERS] Multi column range partition table
Дата
Msg-id CAEZATCU2frKZEWzy=kgmjcyiHpxq2UjJL=-cOgax0dq62gKizw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Multi column range partition table  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [HACKERS] Multi column range partition table  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On 5 July 2017 at 10:43, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> 0001 is your patch to tidy up check_new_partition_bound()  (must be
> applied before 0002)
>

I pushed this first patch, simplifying check_new_partition_bound() for
range partitions, since it seemed like a good simplification, but note
that I don't think that was actually the cause of the latent bug you
saw upthread.

I think the real issue was in partition_rbound_cmp() -- normally, if
the upper bound of one partition coincides with the lower bound of
another, that function would report the upper bound as the smaller
one, but that logic breaks if any of the bound values are infinite,
since then it will exit early, returning 0, without ever comparing the
"lower" flags on the bounds.

I'm tempted to push a fix for that independently, since it's a bug
waiting to happen, even though it's not possible to hit it currently.

Regards,
Dean



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

Предыдущее
От: Kuntal Ghosh
Дата:
Сообщение: Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and >from >=
Следующее
От: tushar
Дата:
Сообщение: Re: [HACKERS] increasing the default WAL segment size