根据 docs
wal_keep_segments (integer) Specifies the minimum number of past log file segments kept in the pg_xlog directory
与此同时，根据我的经验 - 您创建一个从站并将 wal_keep_segments 从默认值更改为 64，然后观察 xlog 的数量开始增长直到达到 64 个文件。我认为这是最大值，而不是最小值。
然后如果你创建了一个超过 16M*64=1GB 的事务，slave 就坏了，说它需要删除 WAL 文件。因为最大文件数比需要的少，对吧？.. 那么问题来了:为什么要MINIMUM？为什么不是 MAXIMUM？
更新:AS 文档在第一句话中指出我在谈论流复制
These settings control the behavior of the built-in streaming replication feature
master，不是slave(没有级联复制)
18.6.1. Sending Server(s)
archive_command 是“什么都不做” cd . 并且 recovery.conf 中的 restore_command 没有设置完全
最佳答案
直接回答你的问题，为什么最小而不是最大？因为新的 WAL 段比 RemoveOldXlogFiles(_logSegNo, recptr) 函数删除旧的 WAL 段增长得更快。
另外，文档中计算WAL段可能数量的公式是错误的。我的 WAL 总是比 checkpoint_segments + wal_keep_segments + 1 更准确的公式是这样的:wal_keep_segments + 2 * checkpoint_segments + 1
这里有一篇老掉牙但非常好的帖子:http://www.postgresql.org/message-id/CAECtzeUeGhwCiNTishH=+kxhiepJsHu7EO0J6-LEVO-ek5oPkg@mail.gmail.com
如果您进行大量插入，您的 WAL 段的增长速度将快于它们被删除的速度。就在这周，我得到了这个。我希望 pg_xlog 保持相对恒定的大小。晚上有一个大型进程在运行，当我第二天早上开始工作时，我的 postgres 实例崩溃了，因为我安装的用来放置这些 WAL 的卷已经完全满了。 Postgres 填满了卷，试图写更多的 WAL，但不能，然后突然死了。幸运的是我们在 pgpool2 后面运行副本。
如果您有好奇心，我鼓励您浏览 postgres 源代码。它很大，而且是用 C 语言编写的，但是代码注释真的很有帮助。这个文件特别有启发性，因为它深入了解检查点如何工作以及如何删除旧的 WAL 段:https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlog.c
关于postgresql - wal_keep_segments 为什么是最小值而不是最大值？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32116292/