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/ 目录大小是否真正收敛。
