我们有一个容量相对较小的 Postgres 数据库，它设置了连续存档以压缩每个 WAL 段并将其发送到 S3。因为它是一个低容量系统，它archive_timeout每 10 分钟左右就会命中一次并归档大部分未使用的 WAL 段，该段过去压缩得非常好，因为它大多只是零。
然而，Postgres 回收其 WAL 段以避免在每个 WAL 交换机上分配新文件的成本，这在高负载情况下很有用，但这意味着在比正常活动更重的突发之后，我们的 WAL 段文件现在已满来自先前段的垃圾，并且根本没有很好地压缩。我们存储了所有这些垃圾的大量副本。
有没有办法减少我们用来保存 WAL 档案的空间量？一些次优的可能性：
以某种方式防止 Postgres 回收 WAL 段，因此它每次都以归零文件开始。文档没有表明有这样做的选项，但我可能已经错过了。
让 Postgres 在开始/结束使用 WAL 段文件时将其归零。同样，文档似乎并不表明这是可能的。
外部归零或删除一些不使用的 WAL 段文件。有没有安全的方法来确定这是哪些文件？
在使用输出归档之前将段的未使用部分归零pg_xlogdump以查找垃圾开始的位置。可能，虽然我不喜欢它。至少通过在 archive 命令中执行此操作，您可以确保 Postgres 不会重用该文件。
仅存档段文件的使用部分，再次通过以pg_xlogdump某种方式解释输出，然后在恢复期间用零填充它。听起来也有可能，虽然我不太喜欢它。
从 9.4 版开始，它现在会自动将 WAL 文件的尾端归零。（实际上它大部分为零，有一些块头没有被清零，但结果仍然是非常可压缩的）。
在 9.2 版本中，有一个名为pg_clearxlogtail您可以使用的程序。您可以在压缩步骤之前将其添加到您的 archive_command 中。
如果您使用的是 9.3，那您就不走运了。
请注意，检查点本身不会导致日志文件切换。可能是 archive_timeout 导致切换。