PostgreSQL：Truncate阻塞pg_class致所有SELECT失效的问题咨询

PostgreSQL 里的 TRUNCATE 属于DDL操作，执行时会对目标表在pg_class系统表中的对应元组加ACCESS EXCLUSIVE锁——这是PostgreSQL最严格的锁级别，会阻塞所有针对该元数据的读取和修改操作。

你贴出的查询是在扫描pg_class、筛选指定schema下非索引/非视图的对象，它需要读取pg_class里的相关元组。当TRUNCATE持有目标表的pg_class元组锁时，这个元数据查询会被阻塞；而pg_class是PostgreSQL的核心系统表，几乎所有查询都需要读取它获取表结构、权限等元数据，一旦这个查询卡住，后续所有依赖pg_class的操作（包括无关表的SELECT）都会排队等待，最终导致全局查询阻塞。

除了放弃使用TRUNCATE，你可以尝试以下几种方案：

• 改用分批DELETE+VACUUM替代：如果数据量不大，直接用DELETE FROM table_name;清空数据，之后执行VACUUM table_name;回收空间。如果数据量较大，建议分批删除（比如DELETE FROM table_name WHERE id BETWEEN x AND y;循环执行），避免长时间持有锁。注意，DELETE会产生大量WAL日志，性能比TRUNCATE差，适合低峰期操作。

• 分区表交换（适合分区场景）：如果你的表是分区表，用ALTER TABLE ... EXCHANGE PARTITION操作快速清空分区，步骤如下：

  1. 创建一个和目标分区结构完全一致的空表：CREATE TABLE empty_table (LIKE target_partition INCLUDING ALL);
  2. 交换分区：ALTER TABLE main_table EXCHANGE PARTITION target_partition WITH TABLE empty_table;
  3. 清空或丢弃空表：TRUNCATE empty_table;（此时操作空表不会影响业务）或者直接DROP TABLE empty_table;
     这个操作是原子性的，锁粒度小，执行速度和TRUNCATE相当，几乎不会阻塞业务。

• 调整TRUNCATE执行时机：把TRUNCATE操作安排在业务低峰期（比如凌晨）执行，减少对正常查询的影响。

• 优化元数据查询的锁行为：针对你贴出的元数据查询，可以设置锁超时，避免它被阻塞后拖垮整个系统。比如在执行该查询前设置：SET lock_timeout = '1000ms';，如果查询在1秒内获取不到锁就直接报错退出，不会一直占着连接导致后续查询排队。

• 应急阻塞排查与处理：当出现阻塞时，用SELECT * FROM pg_stat_activity WHERE state = 'waiting';排查阻塞链，找到持有锁的TRUNCATE进程或者被阻塞的元数据查询，必要时用SELECT pg_terminate_backend(pid);终止长时间阻塞的进程，快速恢复系统。

内容的提问来源于stack exchange，提问作者Vladislav Zhilmanov