From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, amul sul <sulamul(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Multi column range partition table |
Date: | 2017-07-06 09:30:21 |
Message-ID: | CAEZATCU2frKZEWzy=kgmjcyiHpxq2UjJL=-cOgax0dq62gKizw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5 July 2017 at 10:43, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | tushar | 2017-07-06 09:51:41 | Re: increasing the default WAL segment size |
Previous Message | Kuntal Ghosh | 2017-07-06 09:14:14 | Re: WIP patch: distinguish selectivity of < from <= and > from >= |