Re: [HACKERS] Dropping partitioned table drops a previously detached partition

Hi Ashutosh,

On 2017/06/12 20:56, Ashutosh Bapat wrote:
> Hi,
> If we detach a partition and drop the corresponding partitioned table,
> it drops the once-partition now-standalone table as well.

Thanks for the report.  Looks like 8b4d582d279d78 missed the bit about
drop_parent_dependency() that you describe in your analysis below.

> The reason for this is as follows
>     An AUTO dependency is recorded between a partitioned table and partition. In
>     case of inheritance we record a NORMAL dependency between parent
> and child. While
>     detaching a partition, we call RemoveInheritance(), which should have taken
>     care of removing this dependency. But it removes the dependencies which are
>     marked as NORMAL. When we changed the dependency for partitioned case from
>     NORMAL to AUTO by updating StoreCatalogInheritance1(), this function was not
>     updated. This caused the dependency to linger behind even after
> detaching the
>     partition, thus causing the now standalone table (which was once a
> partition)
>     to be dropped when the parent partitioned table is dropped. This patch fixes
>     RemoveInheritance() to choose appropriate dependency.
>
> Attached patch 0001 to fix this.

Looks good to me.  Perhaps, the example in your email could be added as a
test case.

> I see a similar issue-in-baking in case we change the type of
> dependency recorded between a table and the composite type associated
> with using CREATE TABLE ... OF command. 0002 patch addresses the
> potential issue by using a macro while creating and dropping the
> dependency in corresponding functions. There might be more such
> places, but I haven't searched for those.

Might be a good idea too.

Adding this to the open items list.

Thanks,
Amit



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers