Re: Declarative partitioning - another take

From: Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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>, Amit Langote <amitlangote09(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, 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: 2016-12-12 17:14:14
Message-ID: e6c56fe9-4b87-4f64-ac6f-bc99675f3f9e@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
hacky_partitioning_hotfix.diff text/x-patch 959 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2016-12-12 17:16:07 Re: Nested Wait Events?
Previous Message Robert Haas 2016-12-12 17:09:00 Re: new table partitioning breaks \d table to older versions