Hi guys,
Looks like I've just encountered a bug. Please excuse me for the messy
email, I don't have much time at the moment.
Here's the test case:
create table test(val int) partition by range (val);
create table test_1 partition of test for values from (1) to (1000)
partition by range(val);
create table test_2 partition of test for values from (1000) to (2000)
partition by range(val);
create table test_1_1 partition of test_1 for values from (1) to (500)
partition by range(val);
create table test_1_2 partition of test_1 for values from (500) to (1000)
partition by range(val);
create table test_1_1_1 partition of test_1_1 for values from (1) to (500);
create table test_1_2_1 partition of test_1_2 for values from (500) to
(1000);
/* insert a row into "test_1_2_1" */
insert into test values(600);
/* what we EXPECT to see */
select *, tableoid::regclass from test;
val | tableoid
-----+------------
600 | test_1_2_1
(1 row)
/* what we ACTUALLY see */
insert into test values(600);
ERROR: no partition of relation "test_1_1" found for row
DETAIL: Failing row contains (600).
How does this happen? This is how "PartitionDispatch" array looks like:
test | test_1 | test_2 | test_1_1 | test_1_2
which means that this code (partition.c : 1025):
/*
* We can assign indexes this way because of the way
* parted_rels has been generated.
*/
pd[i]->indexes[j] = -(i + 1 + m);
doesn't work, since partitions are not always placed right after the parent
(implied by index "m").
We have to take into account the total amount of partitions we've
encountered so far (right before index "i").
I've attached a patch with a hotfix, but the code looks so-so and has a
smell. I think it must be rewritten. This bug hunt surely took a while: I
had to recheck all of the steps several times.
--
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers