[HACKERS] Dropping partitioned table drops a previously detached partition
От | Ashutosh Bapat |
---|---|
Тема | [HACKERS] Dropping partitioned table drops a previously detached partition |
Дата | |
Msg-id | CAFjFpRdOwHuGj45i25iLQ4QituA0uH6RuLX1h5deD4KBZJ25yg@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: [HACKERS] Dropping partitioned table drops a previously detachedpartition
|
Список | pgsql-hackers |
Hi, If we detach a partition and drop the corresponding partitioned table, it drops the once-partition now-standalone table as well. create table prt1 (a int, b int) partition by range(a); create table prt1_p1 partition of prt1 for values from (0) to (100); select oid, relname, relpartbound, relispartition, relkind from pg_class where relname like 'prt%'; oid | relname -------+--------- 16453 | prt1 16456 | prt1_p1 (2 rows) select * from pg_depend where refobjid = 'prt1'::regclass and objid = 'prt1_p1'::regclass; classid | objid | objsubid | refclassid | refobjid | refobjsubid | deptype ---------+-------+----------+------------+----------+-------------+--------- 1259 | 16456 | 0 | 1259 | 16453 | 0 | a (1 row) alter table prt1 detach partition prt1_p1; -- so the dependency exists even after detach select * from pg_depend where refobjid = 'prt1'::regclass and objid = 'prt1_p1'::regclass; classid | objid | objsubid | refclassid | refobjid | refobjsubid | deptype ---------+-------+----------+------------+----------+-------------+--------- 1259 | 16456 | 0 | 1259 | 16453 | 0 | a (1 row) drop table prt1; -- Oops, we deleted the once-partition now-standalone table as well select oid, relname, relpartbound, relispartition, relkind from pg_class where relname like 'prt%'; oid | relname | relpartbound | relispartition | relkind -----+---------+--------------+----------------+--------- (0 rows) 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. 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. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: