Re: [HACKERS] Multi column range partition table - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: [HACKERS] Multi column range partition table
Date
Msg-id CAEZATCU2frKZEWzy=kgmjcyiHpxq2UjJL=-cOgax0dq62gKizw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Multi column range partition table  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [HACKERS] Multi column range partition table
List 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 by date:

Previous
From: Kuntal Ghosh
Date:
Subject: Re: [HACKERS] WIP patch: distinguish selectivity of < from <= and >from >=
Next
From: tushar
Date:
Subject: Re: [HACKERS] increasing the default WAL segment size