我正在使用运行 Postgresql 8.1.3 和 Slony-I 复制系统（slon 版本 1.1.5）的 SuSE 机器（cat /etc/issue: SUSE Linux Enterprise Server 11 SP1 (i586)）。我们在这台服务器上的两个数据库之间有一个有效的复制设置，它正在生成要发送到我们负责维护的远程机器的日志传送文件。截至今天早上，我们遇到了这个问题。
一段时间以来，我们在这台机器上遇到了奇怪的内存问题——即使剩余大量可用内存，oom-killer 似乎也很惊人。这为我们当前的问题的发生奠定了基础 - 我们昨晚在系统上运行了大规模更新，同时关闭了复制。现在，就目前的情况而言，我们无法复制更改 - slony 正在尝试将所有更改编译到一个庞大的日志文件中，并且在运行大约半小时左右后，它遇到了 oom-killer 问题，该问题似乎重新启动了复制包。由于它一直在尝试重建同一个包，所以它永远不会到达任何地方。
我的第一个问题是：有没有办法限制 Slony 日志传送文件的大小，以便它写出不超过“X”字节（或 K，或 Meg 等），并且在超过该大小后关闭当前的日志传送文件并开始一个新的？在 oom-killer 以合理的规律性命中之前，我们已经能够达到大约 4 megs 的大小，所以如果我能把它限制在那里，我至少可以开始生成更小的文件，并希望最终能通过这个。
我想我的第二个问题是：有没有人有比我要问的更好的解决方案来解决这个问题？很有可能我在看问题时得到了隧道视野，而我真正需要的只是-a-解决方案，而不一定是-my-解决方案。