PostgreSQL自动清理是否阻塞DDL操作？日志分析与阻塞排查

1. PostgreSQL自动清理（auto-vacuum）是否会阻塞同一表上执行ALTER或CREATE查询的其他进程？ #

是的，会阻塞。PostgreSQL的自动清理进程默认持有ShareUpdateExclusiveLock锁，而ALTER TABLE、CREATE TABLE（涉及同表依赖时）这类操作需要获取AccessExclusiveLock——这两种锁是互斥冲突的。

常规自动清理执行时间通常较短，阻塞不会持续太久；但如果是日志中提到的防回卷自动清理（automatic vacuum to prevent wraparound），由于需要扫描全量数据，执行时间会大幅延长，对应的阻塞时间也会更久。

2. 现有日志是否足以证明自动清理是阻塞元凶？若否，还有哪些可能的阻塞进程？ #

日志内容 #

LOG:  automatic vacuum to prevent wraparound of table "my_db.public.event_spl_1740300900": index scans: 0
 pages: 0 removed, 16591962 remain, 0 skipped due to pins, 16300723 skipped frozen
 tuples: 0 removed, 1244397113 remain, 0 are dead but not yet removable, oldest xmin: 1410720248
 buffer usage: 2361602 hits, 6947399 misses, 291262 dirtied
 avg read rate: 3.879 MB/s, avg write rate: 0.163 MB/s
 system usage: CPU: user: 83.69 s, system: 135.74 s, elapsed: 13990.91 s

LOG:  process 113323 acquired AccessExclusiveLock on relation 181282787 of database 180669275 after 5823314.224 ms

结论与分析 #

现有日志不足以直接证明自动清理是阻塞元凶。日志仅记录了防回卷自动清理的执行详情，以及ALTER进程最终获取锁的耗时，但未明确标注该ALTER进程被哪个具体进程阻塞。

可能的阻塞进程包括：

• 其他需AccessExclusiveLock的操作进程：比如其他ALTER TABLE、DROP TABLE、TRUNCATE等操作，这类操作会持有AccessExclusiveLock，完全阻塞后续同表的AccessExclusiveLock请求。
• 手动VACUUM/ANALYZE进程：手动执行的VACUUM、ANALYZE同样会持有ShareUpdateExclusiveLock，与ALTER需要的AccessExclusiveLock互斥。
• 并发索引操作进程：CREATE INDEX CONCURRENTLY、REINDEX CONCURRENTLY执行过程中会持有ShareUpdateExclusiveLock，也会阻塞ALTER操作。
• 长事务进程：未提交的长事务本身不会直接阻塞ALTER，但会导致自动清理无法完成（需等待长事务结束），进而间接延长ALTER的阻塞时间。
• 异常备份进程：如pg_dump备份出现异常时，可能长时间持有ShareLock，该锁与AccessExclusiveLock互斥，从而阻塞ALTER。

内容的提问来源于stack exchange，提问作者Yashodhan Agnihotri