postgresql - 备用数据库上运行的可重复读取事务如何看到 transient ？

Question

在关于事务隔离级别的PostgreSQL文档中，我们可以看到如下内容:

While performing all permanent database writes within Serializable transactions on the master will ensure that all standbys will eventually reach a consistent state, a Repeatable Read transaction run on the standby can sometimes see a transient state which is inconsistent with any serial execution of serializable transactions on the master.

The above text is at the bottom of http://www.postgresql.org/docs/9.4/static/transaction-iso.html

在什么情况下，在热备份上运行的可重复读取事务可能会看到不一致的 transient ？

Answer 1

Geir Bostad 的回答是正确的；我的回应只是为了提供一个例子和可能的解决方法，因为人们常常难以理解这个问题。除了其他答案中引用的 Wiki 页面外，还有 a separate Wiki page just for examples其中包括a "Deposit Report" example看到批处理已关闭但还不能看到批处理的最终详细信息。

热备是只读的，所以它只能看到 transient 序列化异常；数据最终将在一些后续事务中进入一致状态。这与主服务器上的可重复读取事务可能发生的情况相同，而主服务器上的可序列化事务则不可能发生。为防止混淆，热备用不允许可序列化事务，因为您不能(还)保证在那里看到真正可序列化的事务行为。已经讨论过向 WAL 流添加信息以识别可以启动可序列化事务的点，而不会有看到异常的风险，类似于 START TRANSACTION 的 DEFERRABLE 选项| ;这个(或类似的东西)可能会添加到 future 的某个版本中。

对于使用快照隔离的只读事务(包括在 Oracle 或 9.1 之前的 PostgreSQL 版本中标识为可序列化的事务)，最常见的异常类型似乎是 SELECT 列表或汇总批在交易中显示为“已关闭”，而没有看到应包含在批处理中的所有工作。要看到这一点，关闭批处理的事务必须“重叠”(同时运行)一些修改批处理详细信息的事务，关闭批处理的事务必须首先提交，然后(在关闭批处理的事务提交之后和修改批处理详细信息之前)提交)只读事务必须启动并获取其快照。

为防止这种情况，最简单的技术是将主节点上的冲突从读写依赖“升级”为写入冲突。例如，在上面引用的“存款报告”示例中，可以将 deposit_total 列添加到控制表中，当 deposit_no 递增时，该列由 AFTER 触发器设置为零，并且可以将 AFTER 触发器添加到收据表中以更新金额以每张收据的金额为准。这将导致基于控制记录的写入冲突的序列化失败，从而阻止异常传播到副本。