[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  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: [HACKERS] oidin / oidout and InvalidOid
Следующее
От: Andreas Karlsson
Дата:
Сообщение: Re: [HACKERS] oidin / oidout and InvalidOid