PostgreSQL：WAL（预写日志）持续增长，已采取措施仍未解决

核心逻辑回顾 #

未启用归档时，PostgreSQL会在完成checkpoint后，自动清理所有不再被依赖的WAL文件——依赖场景包括活跃复制槽、未结束的长事务/快照、崩溃恢复需求等。结合你已做的操作，以下是进一步排查方向：

1. 排查隐性/残留复制槽 #

已删除不必要的复制槽，但可能存在未被发现的僵尸槽（比如逻辑复制槽、未正常清理的物理复制槽）：

• 执行命令列出所有复制槽：

  SELECT slot_name, plugin, active, wal_status FROM pg_replication_slots;
  

• 对active = false且无业务需求的槽，手动删除：

  SELECT pg_drop_replication_slot('target_slot_name');
  

2. 检查长事务与未释放快照 #

长时间运行的事务或未释放的快照会持续占用WAL，阻止清理：

• 列出所有长时间运行的事务：

  SELECT pid, query, now() - xact_start AS transaction_duration 
  FROM pg_stat_activity 
  WHERE state IN ('idle in transaction', 'active') 
  ORDER BY transaction_duration DESC;
  

• 对无业务必要性的长事务，终止对应进程：

  SELECT pg_terminate_backend(target_pid);
  

3. 验证Checkpoint执行状态 #

Checkpoint未正常完成会导致WAL无法触发清理：

• 查看Checkpoint相关配置：

  SHOW checkpoint_completion_target;
  SHOW max_wal_size;
  

• 检查最近一次Checkpoint的执行情况：

  SELECT checkpoint_start_time, checkpoint_end_time, checkpoint_write_time 
  FROM pg_stat_bgwriter 
  ORDER BY checkpoint_start_time DESC LIMIT 1;
  

• 若Checkpoint执行过慢，可适当调大checkpoint_completion_target（建议0.8-0.9），或根据磁盘容量调整max_wal_size（仅为缓解手段，需先定位根本原因）。

4. 确认WAL清理相关进程状态 #

walwriter、autovacuum launcher进程异常会影响WAL清理：

• 检查进程运行状态：

  SELECT pid, backend_type, state FROM pg_stat_activity 
  WHERE backend_type IN ('walwriter', 'autovacuum launcher');
  

• 若进程异常，可在业务低峰期重启PostgreSQL服务（重启前需确保数据备份完整）。

5. 排查系统级文件锁定 #

第三方工具（如备份工具、监控脚本）可能锁定WAL文件，导致无法删除：

• 在Linux系统下，执行命令检查WAL目录（通常为$PGDATA/pg_wal）的文件占用：

  lsof +D /path/to/your/pg_wal
  

• 终止占用WAL文件的无关进程，再触发手动清理。

验证清理效果 #

执行手动Checkpoint触发WAL清理：

SELECT pg_checkpoint();

随后查看WAL目录下的文件数量变化，确认清理生效。

内容的提问来源于stack exchange，提问作者Andrei Lagutin