Re: [HACKERS] Multi column range partition table
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Multi column range partition table |
Дата | |
Msg-id | 05b0da28-8e8d-2728-8f7f-5a0d1d13a7fd@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Multi column range partition table (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Список | pgsql-hackers |
On 2017/07/06 18:30, Dean Rasheed wrote: > 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 like how simple check_new_partition_bound() has now become. > 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. Oops, you're right. Thanks for the fix. Regards, Amit
В списке pgsql-hackers по дате отправления: