From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | amul sul <sulamul(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 高增琦 <pgf00a(at)gmail(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Erik Rijkers <er(at)xs4all(dot)nl>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org |
Subject: | Re: Declarative partitioning - another take |
Date: | 2017-01-10 09:07:00 |
Message-ID: | 603acb8b-5dec-31e8-29b0-609a68aac50f@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Amul,
On 2017/01/09 17:29, amul sul wrote:
> I got server crash due to assert failure at ATTACHing overlap rang
> partition, here is test case to reproduce this:
>
> CREATE TABLE test_parent(a int) PARTITION BY RANGE (a);
> CREATE TABLE test_parent_part2 PARTITION OF test_parent FOR VALUES
> FROM(100) TO(200);
> CREATE TABLE test_parent_part1(a int NOT NULL);
> ALTER TABLE test_parent ATTACH PARTITION test_parent_part1 FOR VALUES
> FROM(1) TO(200);
>
> I think, this bug exists in the following code of check_new_partition_bound():
>
> 767 if (equal || off1 != off2)
> 768 {
> 769 overlap = true;
> 770 with = boundinfo->indexes[off2 + 1];
> 771 }
>
> When equal is true array index should not be 'off2 + 1'.
Good catch. Attached patch should fix that. I observed crash with the
following command as well:
ALTER TABLE test_parent ATTACH PARTITION test_parent_part1 FOR VALUES FROM
(1) TO (300);
That's because there is one more case when the array index shouldn't be
off2 + 1 - the case where the bound at off2 is an upper bound (I'd wrongly
assumed that it's always a lower bound). Anyway, I rewrote the
surrounding comments to clarify the logic a bit.
> While reading code related to this, I wondered why
> partition_bound_bsearch is not immediately returns when cmpval==0?
partition_bound_bsearch() is meant to return the *greatest* index of the
bound less than or equal to the input bound ("probe"). But it seems to me
now that we would always return the first index at which we get 0 for
cmpval, albeit after wasting cycles to try to find even greater index.
Because we don't have duplicates in the datums array, once we encounter a
bound that is equal to probe, we are only going to find bounds that are
*greater than* probe if we continue looking right, only to turn back again
to return the equal index (which is wasted cycles in invoking the
partition key comparison function(s)). So, it perhaps makes sense to do
this per your suggestion:
@@ -1988,8 +2018,11 @@ partition_bound_bsearch(PartitionKey key,
PartitionBoundInfo boundinfo,
if (cmpval <= 0)
{
lo = mid;
*is_equal = (cmpval == 0);
+
+ if (*is_equal)
+ break;
}
Thanks,
Amit
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-some-wrong-thinking-in-check_new_partition_bound.patch | text/x-diff | 8.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-01-10 09:17:54 | Re: Declarative partitioning - another take |
Previous Message | tushar | 2017-01-10 08:49:13 | Re: Parallel bitmap heap scan |