题：
有没有办法告诉Postgres（9.2）“将pg_xlog所有WAL文件合并回非WAL数据文件，然后删除所有成功合并的WAL文件？
我希望能够“强制”这一行动; 即checkpoint_segments或归档设置应该被忽略。 文件系统WAL缓冲区（ pg_xlog ）目录应该清空或者几乎清空。 如果pg_xlog目录使用的部分或全部空间被数据目录占用，那就好了; 我们的DBA已经要求文件（即数据目录，而不是sql）数据库备份，没有任何积压的WAL，但空间消耗不是问题。
在这个操作过程中接近零的WAL活动是一个很好的约束。 我可以确保数据库服务器在此过程中closures或不可连接（零用户生成事务负载）。
实质上，我希望Postgres临时忽略归档/检查点保留策略，并将所有WAL活动刷新到核心数据库文件，使pg_xlog与最近创build的数据库保持相同的状态 – 只有很less的WAL文件。
我试过的东西：
我知道pg_basebackup实用程序执行类似这样的事情（它会生成一个Postgres实例的数据目录的几乎所有WALs合并的副本），但是我们还没有准备好在我们所有的系统上使用它，因为我们还在testing复制设置; 我希望有一个更短期的解决scheme。
我已经尝试发出CHECKPOINT命令，但是他们只是回收一个WAL文件并将其replace为另一个（也就是说，如果他们执行任何操作;如果我在数据库空闲时间发出这些命令，它们什么也不做）。 pg_switch_xlog()同样只是强制切换到下一个日志段; 它不刷新所有排队/缓冲区段。
我也玩过pg_resetxlog工具。 这种工具types是做我想做的，但它的所有使用文档似乎表明，它破坏（而不是冲出事务日志，并进入主要数据文件）的部分或全部WAL数据。 这种印象是否准确？ 如果不是，我可以在零WAL活动期间使用pg_resetxlog强制将所有排队的WAL数据刷新为非WAL数据？ 如果答案是否定的，我怎样才能达到这个目标呢？
谢谢！
。 。 。 有东西告诉我你的DBA不是Postgres的人？ 🙂
根据你的意见，听起来像你正在寻找的解决scheme最接近的是启动数据库（使用您的基础备份），并发出CHECKPOINT ，然后closures该数据库并备份。 这将把“追赶”日志中的WAL数据刷新到主数据库文件，并为您留下一个“空”WAL（虽然您仍然会有几个环节需要实际启动服务器和validation一致性）。
确保备份的唯一方法是将所有数据刷新到主数据库文件，然后closures数据库以进行备份。
我不会build议做这些静态备份，这听起来就像你在做什么。 只要坚持按照Postgres手册创build的备份，如果您需要激活它，请按照本手册中的说明正常启动服务器。
我真的不能想到你的数据库pipe理员正在请求什么有效的原因 – Postgres重播你在pg_stop_backup()命令后收集的日志文件的简短启动延迟是不值得做一些奇怪而不同的事情，真正的程序，以及你需要做的testing数量来validation你提出的任何新程序与标准程序一样强大，这使得这是一个没有吸引力的选项恕我直言。
根据手册，显然，从站/stream/热备份的过程稍有不同。
如果你的DBA 真的想要最小数量的WAL段，我会build议我使用的解决scheme：
从这个备份中恢复本质上与激活一个从服务器相同 – 启动从服务器并创build恢复触发器文件。
有一些技巧来设置这个 – 没有任何不在手册中涵盖，但显然你想要彻底的testing。