On 2017/06/12 20:56, Ashutosh Bapat wrote:
> 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.
> case of inheritance we record a NORMAL dependency between parent
> and child. While
> detaching a partition, we call RemoveInheritance(), which should have
> care of removing this dependency. But it removes the dependencies which
> marked as NORMAL. When we changed the dependency for partitioned case from
> NORMAL to AUTO by updating StoreCatalogInheritance1(), this function was
> updated. This caused the dependency to linger behind even after
> detaching the
> partition, thus causing the now standalone table (which was once a
> to be dropped when the parent partitioned table is dropped. This patch
> 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
> 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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: