1.1 不开启归档时
文件数量受下面几个参数控制，通常不超过
或
checkpoint_segments + wal_keep_segments + 1个文件。
如果一个旧段文件不再需要了会重命名然后继续覆盖使用，如果由于短期的日志输出高峰导致了超过
3 * checkpoint_segments + 1个文件，直接删除文件。
1.2 开启归档时
文件数量：删除归档成功的段文件
抽象来看一个运行的PG生成一个无限长的WAL日志序列。每段16M，这些段文件的名字是数值命名的，反映在WAL序列中的位置。在不用WAL归档的时候，系统通常只是创建几个段文件然后循环使用，方法是把不再使用的段文件重命名为更高的段编号。
当且仅当归档命令成功时，归档命令返回零。 在得到一个零值结果之后，PostgreSQL将假设该WAL段文件已经成功归档，稍后将删除段文件。一个非零值告诉PostgreSQL该文件没有被归档，会周期性的重试直到成功。
2 PG源码分析2.1 删除逻辑
触发删除动作
wal_keep_segments判断（调用这个函数修改_logSegNo，然后再传入RemoveOldXlogFiles）
删除逻辑
2.2 归档逻辑
2.3 ready生成逻辑
2.4 总结
ready文件只要满足archive_mode=on和wal_lever>=archive，就总会生成（XLogWrite函数调用生成）
因为archive_command设置空，所以ready文件的消费完全由外部程序控制
done文件的处理由PG完成，两个地方会触发done文件处理，检查点和重启点
处理多少done文件受wal_keep_segments和replication_slot控制（KeepLogSeg函数）
3 WAL段累积的原因（长求总?）注意：无论如何注意不要手动删除xlog文件
注意：checkpoint产生的日志回不立即生成ready文件，是在下一个xlog后一块生成的
3.1 ReplicationSlot
打开流了复制槽
删除
删除后PG会在下一个checkpoint清理xlog
3.2 较大的wal_keep_segments
检查参数配置，注意打开这个参数会使xlog和ready有一定延迟
3.3 回收出现问题
如果不使用PG自动回收机制，数据库依赖外部程序修改.ready文件，需要检测回收进程
3.4 检查点间隔过长
检查参数配置
以上为个人经验，希望能给大家一个参考，也希望大家多多支持七叶笔记。如有错误或未考虑完全的地方，望不吝赐教。
