Re: [HACKERS] dropping partitioned tables without CASCADE - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] dropping partitioned tables without CASCADE
Date
Msg-id 9884e0dd-7ef5-7e22-c56a-a18bcb585123@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] dropping partitioned tables without CASCADE  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: [HACKERS] dropping partitioned tables without CASCADE  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
On 2017/02/27 13:35, Ashutosh Bapat wrote:
> On Mon, Feb 27, 2017 at 8:08 AM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> On 2017/02/26 5:30, Simon Riggs wrote:
>>> On 23 February 2017 at 16:33, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>
>>>>  I'll be happy to review
>>>
>>> Patch looks OK so far, but fails on a partition that has partitions,
>>> probably because of the way we test relkind in the call to
>>> StoreCatalogInheritance1().
>>
>> Thanks for the review.
>>
>> I could not reproduce the failure you are seeing; could you perhaps share
>> the failing test case?  Here's mine that seems to work as expected:
>>
>> create table p (a int, b char) partition by list (a);
>> create table p1 (a int, b char) partition by list (b);
>> alter table p attach partition p1 for values in (1);
>>
>> -- add a partition to p1
>> create table p1a (like p1);
>> alter table p1 attach partition p1a for values in ('a');
>>
>> create table p2 partition of p for values in (1)
>>
>> \d+ p
>> <snip>
>> Partition key: LIST (a)
>> Partitions: p1 FOR VALUES IN (1),
>>             p2 FOR VALUES IN (2)
>>
>> -- this works (remember that p1 is a partitioned table)
>> drop table p1;
>> DROP TABLE
>>
>> \d+ p
>> <snip>
>> Partition key: LIST (a)
>> Partitions: p2 FOR VALUES IN (2)
>>
>>> Please add a test for that so we can check automatically.
>>
>> OK, done.
> 
> Isn't list_range_parted multilevel partitioned table. It gets dropped
> in the testcases. So, I guess, we already have a testcase there.

I thought Simon meant the test case where a partition that is itself
partitioned is dropped.  At least that's what I took from "... fails *on*
partition that has partitions".  So in the example I posted, drop table p1.

Anyway, there might be the confusion that *only* the root level
partitioned table is of RELKIND_PARTITIONED_TABLE.  That's not true - any
partitioned table (even one that's a partition) is of that relkind.  So
the condition in the call to StoreCatalogInheritance1() is correct.  The
following hunk:

@@ -10744,7 +10756,9 @@ CreateInheritance(Relation child_rel, Relation
parent_rel)    StoreCatalogInheritance1(RelationGetRelid(child_rel),
RelationGetRelid(parent_rel),                            inhseqno + 1,
 
-                             catalogRelation);
+                             catalogRelation,
+                             parent_rel->rd_rel->relkind ==
+                                            RELKIND_PARTITIONED_TABLE);

Thanks,
Amit





pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Proposal : Parallel Merge Join
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Parallel bitmap heap scan