直接回答你的问题，为什么最小，为什么不最大？因为新WAL段的增长速度快于RemoveOldXlogFiles(_logSegNo, recptr)函数删除旧段的速度。
此外，计算文档中WAL段的可能数量的公式是错误的。我总是比checkpoint_segments + wal_keep_segments + 1多一些WAL，一个更准确的公式是：wal_keep_segments + 2 * checkpoint_segments + 1
这里有一个老的，但真的很好的帖子：http://www.postgresql.org/message-id/CAECtzeUeGhwCiNTishH=+kxhiepJsHu7EO0J6-LEVO-ek5oPkg@mail.gmail.com
如果你做大量的插入，你的WAL段将增长速度比他们可以删除。这让我在这周。我希望pg_xlog保持相对恒定的大小。晚上有一个大的进程运行，当我第二天早上开始工作时，我的postgres示例崩溃了，因为我挂载的文件卷完全满了。波斯特格雷斯填满了这卷书，试图写更多的沃尔，但写不出，突然死了。幸运的是，我们在pgpool2后面运行副本。
如果你有好奇心，我鼓励你浏览postgres的源代码。它是巨大的，用C语言编写的，但是代码注解真的很有帮助。这个文件特别有启发性，因为它深入到检查点的工作原理以及如何删除旧的WAL段的螺母和螺栓：https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlog.c

xlog的数量开始增长直到达到64个文件。我认为是最大值，不是最小值。
不，这不是上限。最大值的公式在http://www.postgresql.org/docs/current/static/wal-configuration.html的文档中给出
总是至少有一个WAL段文件，并且通常不超过（2 + checkpoint_completion_target）* checkpoint_segments + 1或checkpoint_segments + wal_keep_segments + 1个文件。每个段文件通常为16MB（尽管在构建服务器时可以更改此大小）。您可以使用此选项来估计WAL的空间需求。
您提到的关于需要删除WAL文件的从机的问题应结合上下文来查看，即日志传送是如何配置的，还是根本没有配置，以及您是否使用热备份或流式复制。
请参阅https://wiki.postgresql.org/wiki/Binary_Replication_Tutorial以获得可能比主要文档更容易理解的解释。

这是minumum，因为WAL文件保留的情况下，你需要恢复，他们可以超过wal_keep_segments在很短的时间内，但永远不会少，因为WAL文件的数量决定了多少备用服务器可以落后之前无法赶上。

就像生活中的许多其他事情一样，这也是“由于历史原因”。自PostgreSQL 13.0版本以来，存在另一个名为max_slot_wal_keep_size的配置参数，它可以与永久复制插槽一起使用，允许插槽自动定义正确的最小值，并使用max_slot_wal_keep_size设置最大值，以避免在从无法跟上的情况下耗尽主磁盘空间。
基本上，旧的风格（版本12.x或更低版本）是“使用wal_keep_segments来猜测正确的最小/实际大小”或“使用无限的最大大小，希望你没有耗尽磁盘空间（永久复制插槽）”。