我使用的是PostgreSQL 12,其中有一个分区表,这个表有旧的分区需要删除,我看过这样的代码,旧的分区先被分离,然后才被删除:
ALTER TABLE partitioned_table DETACH PARTITION partitioned_table_1;
DROP TABLE partitioned_table_1;
是否有任何理由在删除分区之前分离分区?仅删除分区而不分离是否会影响对数据库的其他查询?
我使用的是PostgreSQL 12,其中有一个分区表,这个表有旧的分区需要删除,我看过这样的代码,旧的分区先被分离,然后才被删除:
ALTER TABLE partitioned_table DETACH PARTITION partitioned_table_1;
DROP TABLE partitioned_table_1;
是否有任何理由在删除分区之前分离分区?仅删除分区而不分离是否会影响对数据库的其他查询?
2条答案
按热度按时间eoigrqb61#
手册上的。
DROP TABLE partitioned_table_1;
表示删除表。ACCESS EXCLUSIVE父表上的锁。ALTER TABLE partitioned_table DETACH PARTITION partitioned_table_1;
表示partitioned_table_1仍将存在。ACCESS EXCLUSIVE父表上的锁分离的分区继续作为独立表存在,但不再与分离它的表有任何联系。
在postgresql 14中,
DETACH PARTITION partitioned_table_1 CONCURRENTLY
SHARE UPDATE EXCLUSIVE锁定父表。更多信息:https://www.postgresql.org/docs/12/sql-altertable.htmlhttps://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-DETACH-PARTITION https://www.postgresql.org/docs/current/ddl-partitioning.html
ctehm74n2#
这是一个有趣的问题。
让我们参考这个分区表结构(取自PgAnalyze blog post)
说到锁定过程,两种类型的操作:
对比
这两种方法都需要在父表
people_partitioned
上取一个ACCESS EXCLUSIVE LOCK
,当锁处于适当位置时,该ACCESS EXCLUSIVE LOCK
阻塞针对people_partitioned
的任何SELECT
(没有FOR UPDATE/SHARE
)语句。但是,当您需要对分区表执行额外的维护操作时,detach-drop策略确实非常有用。您很可能希望在永久删除该分区之前,使用
COPY
、pg_dump
创建该分区的备份,执行数据聚合、分析等操作。由于该分区表已被分离,它将不与父表发生锁冲突。现在,您可能想知道,您仍然可以执行这些维护操作,而删除分区的时间表仍然存在?
同样,如果有任何操作需要父表上的排他锁(例如,正在创建/删除另一个新分区,这也需要父表上的排他锁),则上述维护操作将被阻止,直到锁冲突得到解决。
总之,从根分区表中detach-drop分区表通常比immediate-drop更安全。对现有分区表结构的任何操作都不应妨碍对分离分区的维护操作,反之亦然
Postgres DDL声明性分区(含用例)