在有关事务隔离级别的 PostgreSQL 文档中，我们可以阅读以下内容：
虽然在 master 上的 Serializable 事务中执行所有永久数据库写入将确保所有备用数据库最终达到一致状态，但在备用数据库上运行的可重复读取事务有时会看到与任何串行执行 serializable 不一致的瞬态状态主服务器上的事务。
上面的文字在http://www.postgresql.org/docs/9.4/static/transaction-iso.html的底部
在热备用上运行的可重复读取事务在什么情况下会出现不一致的瞬态？
【问题讨论】：
标签： postgresql transactions database-replication transaction-isolation
Geir Bostad 的回答是正确的；我的回应只是为了提供一个示例和可能的解决方法，因为人们经常难以理解这一点。除了另一个答案中引用的 Wiki 页面之外，还有 a separate Wiki page just for examples，其中包括 a "Deposit Report" example 看到批次已关闭但还无法看到批次的最终详细信息。
热备是只读的，所以它只能看到暂时的序列化异常；数据最终会在一些后续事务中稳定到一致的状态。这与主服务器上的可重复读取事务可能发生的情况相同，而主服务器上的可序列化事务则不可能。为防止混淆，在热备用上不允许可序列化事务，因为（还）不能保证在那里看到真正的可序列化事务行为。一直在讨论向 WAL 流添加信息，以识别可以启动可序列化事务的点而不会出现异常风险，类似于 START TRANSACTION 的 DEFERRABLE 选项；这个（或类似的）可能会在未来的某个版本中添加。
对于使用快照隔离的只读事务（包括在 Oracle 或 9.1 之前的 PostgreSQL 版本中标识为可序列化的事务），最常见的异常类型似乎是 SELECT 列表或汇总批处理在事务中显示为“已关闭”，而没有看到应包含在批处理中的所有工作。要看到这一点，关闭批处理的事务必须“重叠”（同时运行）一些修改批处理详细信息的事务，关闭批处理的事务必须首先提交，然后（在关闭批处理的事务已提交之后和修改批处理详细信息的事务之前提交）只读事务必须启动并获取其快照。
为了防止这种情况，最简单的技术是将主节点上的冲突从读写依赖“提升”为写-写冲突。例如，在上面引用的“存款报告”示例中，可以将 deposit_total 列添加到控制表中，当 deposit_no 增加时，AFTER 触发器将其设置为零，并且可以将 AFTER 触发器添加到收据表中以更新金额基于每张收据的金额。这将导致基于控制记录的写入冲突的序列化失败，从而阻止异常传播到副本。
【讨论】：
REPEATABLE READ 和 Select（只读）查询是否合适与恢复冲突有关的错误？
批处理和类似应用程序似乎会发生这种情况。
我在一个关于 SSI 的 wiki 页面中找到了有关该主题的一些信息，并从 postgresql-hackers 邮件列表中找到了一些背景细节，他们讨论了如何处理热备用上的序列化。
Kevin Grittner 在他的post 中写道：
发生这种情况的最常见和最令人担忧的情况是，在我的 看来，是批处理。这在金融界非常普遍 应用程序，并且往往也会出现在许多其他地方。
[..]
但是，备用数据库上的查询可能会在以下情况下看到 transient 异常 他们运行查询，如果在 事务流中同一点的主控。这只能 发生在两个并发事务中，其中一个 似乎排在第二位，因为对方无法阅读它所写的内容， 首先提交。
[..]
在 SSI 下，其中一项交易将被取消以防止这种情况发生。 我们的实现将始终允许关闭批次的更新 完成，插入或选择细节将是 因序列化失败而回滚，具体取决于 这些事务中的操作。如果插入失败，可以 重试，并将降落在新批次中 - 制作列表 省略它的批处理。如果批次详细信息的列表是 取消，这将是因为插入到旧批次中已提交 在它发现问题之前，立即重试选择 将看到完整的批次内容。
热备用真的不能 参与谓词锁定和事务取消 主人。
【讨论】：