手册上的。

• 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 CONCURRENTLYSHARE UPDATE EXCLUSIVE锁定父表。更多信息：https://www.postgresql.org/docs/12/sql-altertable.html
https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-DETACH-PARTITION https://www.postgresql.org/docs/current/ddl-partitioning.html

这是一个有趣的问题。
让我们参考这个分区表结构（取自PgAnalyze blog post）

说到锁定过程，两种类型的操作：

• • 立即删除分区表（立即删除）**

DROP TABLE people_partitioned_birthdays_1800_to_1850;

对比

• • 从根（父）表分离分区表，然后将其删除（detach-drop）**

ALTER TABLE people_partitioned DETACH PARTITION people_partitioned_birthdays_1800_to_1850;
DROP TABLE people_partitioned_birthdays_1800_to_1850;

这两种方法都需要在父表people_partitioned上取一个ACCESS EXCLUSIVE LOCK，当锁处于适当位置时，该ACCESS EXCLUSIVE LOCK阻塞针对people_partitioned的任何SELECT（没有FOR UPDATE/SHARE）语句。
但是，当您需要对分区表执行额外的维护操作时，detach-drop策略确实非常有用。您很可能希望在永久删除该分区之前，使用COPY、pg_dump创建该分区的备份，执行数据聚合、分析等操作。由于该分区表已被分离，它将不与父表发生锁冲突。
现在，您可能想知道，您仍然可以执行这些维护操作，而删除分区的时间表仍然存在？

-- perform maintenance action on people_partitioned_birthdays_1800_to_1850 ...
DROP TABLE people_partitioned_birthdays_1800_to_1850;

同样，如果有任何操作需要父表上的排他锁（例如，正在创建/删除另一个新分区，这也需要父表上的排他锁），则上述维护操作将被阻止，直到锁冲突得到解决。
总之，从根分区表中detach-drop分区表通常比immediate-drop更安全。对现有分区表结构的任何操作都不应妨碍对分离分区的维护操作，反之亦然

• 参考 *

Postgres DDL声明性分区（含用例）