我遇到了一个持续时间更长的问题。我使用slony将数据库从主服务器复制到从服务器，并从该从服务器复制到其他三个备份服务器。每隔2-3周就有一次关键的重复问题，只发生在一个特定的表上（数据库中很大，但不是最大的）。
它开始像一年前一样出现在Postgres 8.4和slony 1上，我们切换到了2.0.1。后来我们将其升级到2.0.4，并成功地将slony升级到2.1.3，这是我们的当前版本。我们在同一台计算机上开始了新的复制，直到今天一切都很顺利。我们在同一张表上得到了相同的重复键错误（当然每次都有不同的键）。
清理它的解决方案只是删除从节点上的无效密钥（它分布在所有节点上），然后一切都会重新开始。数据未损坏。但问题的根源仍未解决。
在谷歌上，我没有发现任何与这个问题有关的内容（我们没有在任何表上使用truncate，也没有改变表的结构）。
有什么办法吗？
当我们的设置中出现此问题时，发现master数据库的架构比slave数据库的架构旧，并且没有针对该特定列的UNIQUE约束。所以，我的建议是：
- 确保主表实际上具有约束
如果不是：
- 清洁桌子
- 添加约束
其他：
- 撤销所有客户端的写入权限，复制表的slony除外
正如Craig所说，这通常是对副本的写入事务。因此，首先要做的是验证权限。如果这种情况持续发生，您可以做的是开始记录副本读取器的连接，并将它们保留在身边，这样当问题发生时，您就可以追踪坏元组的来源。然而，这可能会生成大量日志，所以您可能想看看在多大程度上可以首先缩小范围。你大概知道这是从哪个复制品开始的，所以你可以从那里开始。
我会发现一个特别关注的领域是，如果你有一个用户定义的函数来写，会发生什么。一个偶然的观察者可能不会在查询中发现这一点，连接池管理器也可能不会。