sql - PostgreSQL遇到序列化失败的条件是什么？

Question

The PostgreSQL manual page在可序列化隔离级别上声明:

[Like] the Repeatable Read level, applications using this level must be prepared to retry transactions due to serialization failures.

在可重复读取或可序列化级别遇到序列化失败的条件是什么？

我试图通过运行 psql 的两个实例来引发序列化失败，但即使事务由一个实例提交，另一个实例在可序列化级别的事务中提交，而另一个实例提交，已成功提交更改。两者都只是将记录插入表中，所以也许我需要尝试更复杂的方法。

基本上，我试图了解在序列化失败的情况下会发生什么以及序列化失败是如何发生的。

Answer 1

序列化失败的可能原因有很多。从技术上讲，两个事务之间的死锁是序列化失败的一种形式，如果对模式(数据库结构)进行并发修改，则可能在任何隔离级别发生。由于您询问的是 PostgreSQL，因此您应该知道在 PostgreSQL 中，这种类型的序列化失败会得到一个与其他失败不同的 SQLSTATE:“40P01”。所有其他序列化失败返回“40001”。本答案的其余部分将重点关注 PostgreSQL 中的这些非死锁变体。

在事件副本(“热备用”)之外，这些只能发生在两个更严格的隔离级别:可重复读取和可序列化。在 REPEATABLE READ 级别，这些只会因为写入冲突而发生——两个并发事务试图更新或删除相同(现有)的行。进行尝试的第一个事务锁定该行并继续。如果它提交，则第二个事务将因序列化失败而失败。如果第一个事务因任何原因回滚，则被阻止的事务将被释放以继续进行，并将在该行上获得自己的锁。这种行为与交易期间的单个“快照”相结合，也称为快照隔离。

在 PostgreSQL 9.1 版之前，SERIALIZABLE 事务的工作方式完全相同。从 9.1 开始，PostgreSQL 使用一种称为可序列化快照隔离的新技术来确保任何一组可序列化事务的行为与这些事务的一些串行(一次一个)执行完全一致。在 9.1 中使用 SERIALIZABLE 事务时，您的应用程序应该为除 ROLLBACK 之外的任何语句的序列化失败做好准备——即使是只读事务，甚至是 COMMIT。有关详细信息，请参阅位于 http://www.postgresql.org/docs/current/interactive/transaction-iso.html 的 PostgreSQL 文档页面。或者 Wiki 页面给出了序列化失败如何在新的、更严格的隔离级别发生的示例，地址为 http://wiki.postgresql.org/wiki/SSI。

如果您正在使用热备功能，如果有一个长时间运行的查询，您可能会在只读副本上遇到序列化失败，而维护数据的稳定 View 也需要数据库预先停止复制长的。有一些配置设置允许您平衡复制数据的“新鲜度”与长时间运行查询的容忍度。一些用户可能希望创建多个副本，以便他们可以获得最新数据(甚至可能选择同步复制)，同时允许另一个副本根据需要滞后以服务长时间运行的查询。

编辑以提供另一个链接:标题为 Serializable Snapshot Isolation in PostgreSQL 的论文，在第 38 届超大型数据库国际 session 上发表，提供了比其他链接更多的细节和观点，以及为该实现奠定基础的论文引用。