max_wal_size不是硬上限而是检查点目标值；WAL持续增长主因是检查点未及时触发、归档阻塞或replication slot滞留，需综合调优checkpoint参数、归档命令及slot管理。

max_wal_size 超了但 WAL 还在涨？不是配置没生效，是检查点没触发

PostgreSQL 的 max_wal_size 不是硬上限，而是“目标值”——它只在检查点（checkpoint）时起作用。WAL 文件不会实时清理，而是在检查点完成后，把不再需要的旧段文件批量回收。如果检查点间隔太长（比如 checkpoint_timeout 设为 1h），或者写入压力持续很高导致检查点被延迟（checkpoint_completion_target 拉长了实际耗时），WAL 就会一路冲过 max_wal_size，甚至翻倍。

常见错误现象：pg_wal/ 目录大小远超 max_wal_size，但日志里没有报错，pg_stat_bgwriter 显示 checkpoints_timed 很少、checkpoints_req 却频繁上升。

• 确认检查点是否真在发生：查 SELECT now() - last_checkpoint FROM pg_control_checkpoint();
• 调低 checkpoint_timeout（例如从 5min 改为 3min），让时间驱动的检查点更勤快
• 避免把 checkpoint_completion_target 设太高（如 0.9），否则单次检查点拖太久，WAL 积压风险反而加大
• 注意：增大 max_wal_size 本身不减少 WAL 生成量，只是放宽回收窗口——治标不治本

min_wal_size 设太小会导致反复 recycle 和性能抖动

min_wal_size 的作用是“保底预留”，防止检查点后 WAL 文件被清空太多，下次写入又要立刻新建和同步。但它不是越小越好。设得太低（比如 1GB），在中高并发事务场景下，检查点一完成，系统就删掉大量 WAL 段；紧接着新事务涌入，又得快速创建、初始化、同步一堆新段文件——这个过程会明显拉高 sync 延迟，表现为偶发的写入卡顿。

使用场景：适合写入平稳、事务体量小的库；对 OLTP 或逻辑复制上游库，它容易成为隐形瓶颈。

• 典型症状：监控看到 pg_stat_bgwriter 中 wal_recycled 高频跳变，同时 pg_stat_database 的 write_time 出现毛刺
• 合理值参考：设为 max_wal_size 的 20%～50%，例如 max_wal_size = 4GB → min_wal_size = 1GB 到 2GB
• 别把它当成“节省磁盘空间”的手段——WAL 占用空间主要由活跃事务量和检查点节奏决定，不是靠压 min_wal_size 能省出来的

归档开启时 max_wal_size 失效？其实是归档积压阻塞了 WAL 回收

当 archive_mode = on 且归档命令（archive_command）执行慢或失败，WAL 文件即使已过检查点也不会被删除或 recycle，因为 PostgreSQL 必须确保每个 WAL 段都成功归档后才敢释放。这时 max_wal_size 完全不起作用，pg_wal/ 会持续膨胀直到磁盘满。

错误现象：pg_wal/ 目录里大量 000000010000000A000000xx 文件堆积，pg_stat_archiver 显示 failed_count > 0 或 last_failed_time 很近。

• 立刻查归档日志：tail -n 50 $PGDATA/log/*.log | grep "archive command"
• 临时缓解：停掉写入，手动运行失败的 archive_command 命令，再 pg_ctl reload 触发重试
• 长期方案：归档命令必须幂等、超时可控（如加 timeout 30s）、失败时明确退出非零码，否则 PG 无法识别失败
• 注意：archive_timeout 只影响“多久强制切一个归档文件”，不解决归档卡住的问题

修改后不生效？别忘了 wal_keep_size 和 replication slot 的隐性占用

即便 max_wal_size 和 min_wal_size 配置正确，WAL 仍可能居高不下——因为 wal_keep_size（或旧版 wal_keep_segments）和逻辑/物理 replication slot 会强制保留指定数量的 WAL 文件，完全绕过 max_wal_size 控制逻辑。

最容易被忽略的点：replication slot 一旦创建，就会一直保留它“需要”的最老 WAL，哪怕下游断连数天，PG 也不敢删。这时候看 pg_replication_slots，restart_lsn 滞后越多，占的 WAL 就越多。

• 查隐患：运行 SELECT slot_name, plugin, restart_lsn, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) / 1024 / 1024 AS mb_behind FROM pg_replication_slots;
• 清理僵尸 slot：确认下游已废弃，就用 SELECT pg_drop_replication_slot('slot_name');
• wal_keep_size 值建议保守：除非做流复制备用节点，否则设为 64MB～256MB 足够，不必盲目调大
• 注意：wal_keep_size 和 max_wal_size 是叠加关系，不是替代关系

WAL 空间失控很少是单一参数问题，通常是检查点节奏、归档可靠性、replication slot 状态三者叠加的结果。改完配置一定要盯 2～3 个检查点周期，看 pg_wal/ 目录大小是否真正收敛。