设为0.9不一定让写入更平滑，它仅控制脏页刷盘在checkpoint_timeout时间内的占比；需i/o能力、脏页生成速率稳定，否则仍会触发紧急检查点。
checkpoint_completion_target 设为 0.9 真的能让写入更平滑吗？
不一定。它只控制「检查点实际持续时间」占「目标检查点间隔」的比例，不是写入负载的调节器。设成 0.9 意味着 PostgreSQL 会尽量把脏页刷盘动作摊开在 90% 的 checkpoint_timeout 时间内完成——前提是系统 I/O 能跟上、脏页生成速率稳定、且没有突发写入高峰。
- 如果
checkpoint_timeout = 300（5 分钟），checkpoint_completion_target = 0.9就会尝试把刷盘任务控制在 270 秒内做完，留 30 秒空档 - 但若这期间有大量
UPDATE或COPY，脏页生成速度远超刷盘能力，系统仍会触发「紧急检查点」或出现too many checkpoints日志 - SSD 上效果通常比 HDD 明显，因为随机写延迟低，能更好响应调度节奏
为什么调高到 0.9 反而导致 wal_keep_size 不够？
延长刷盘窗口本身不直接增加 WAL 保留量，但间接放大了 WAL 滞后风险：当检查点拉得长、刷盘慢，主库可能提前覆盖掉备库还没来得及读取的 WAL 文件，尤其在流复制场景下容易触发 could not receive data from WAL stream: ERROR: requested WAL segment has already been removed。
-
wal_keep_size是静态水位线，不随checkpoint_completion_target自动调整 - 设为
0.9后，单次检查点周期内产生的 WAL 量未必变多，但 WAL 生效与回收的时间差被拉长，需预留更多缓冲空间 - 建议同步调高
wal_keep_size至至少2×原值（例如从128MB改为256MB），并观察pg_stat_replication中的replay_lag
和 synchronous_commit = off 一起用会放大什么风险？
会显著提高崩溃后数据丢失概率，且这种丢失是「静默」的——事务返回成功，但对应 WAL 可能根本没落盘，连检查点都来不及覆盖。
-
checkpoint_completion_target = 0.9关注的是「已提交事务的 WAL 如何被刷盘」，而synchronous_commit = off允许客户端在 WAL 还在内核 buffer 里时就收到成功响应 - 两者叠加时，一次批量写入可能产生大量脏页 + 大量未刷 WAL；检查点虽努力平滑刷脏页，但 WAL 本身已处于高危状态
- 典型错误现象：服务重启后发现最近几秒的 INSERT 全部消失，且日志里查不到对应 WAL 归档失败记录
如何验证 0.9 是否真起作用？
别只看配置是否生效，重点查 pg_stat_bgwriter 里的运行时指标，它们反映真实调度效果。
- 关注
checkpoints_timed和checkpoints_req的比值：若后者占比持续 > 10%，说明强制检查点太多，0.9的平滑意图已被频繁写压破坏 - 计算
checkpoint_write_time / (checkpoint_sync_time + checkpoint_write_time)，理想值应接近0.9；明显偏低（如 0.3）说明刷盘太快，可能是bgwriter_lru_maxpages太小或 I/O 能力过剩 - 用
SELECT now() - pg_postmaster_start_time();对照pg_stat_bgwriter.checkpoint_time，确认检查点是否真的按预期间隔分布，而非扎堆发生
真正难调的从来不是参数值本身，而是脏页生成节奏和底层存储响应之间的咬合精度——磁盘延迟能抖动 20ms，你的 0.9 就可能变成 0.6 或 1.0。
