READ COMMITTED 是否总是在序列化失败后重新开始而 SERIALIZABLE 只是失败？

Question

在PostgreSQL Concurrency With MVCC 页面上，它说：

知道你在想什么：同时更新同一行的两个事务怎么样？这就是事务隔离级别的用武之地。Postgres 基本上支持两种模型，允许您控制如何处理这种情况。默认值 READ COMMITTED 在初始事务完成后读取行，然后执行语句。如果行在等待时发生更改，它基本上会重新开始。例如，如果您使用 WHERE 子句发出 UPDATE，则 WHERE 子句将在初始事务提交后重新运行，如果仍然满足 WHERE 子句，则执行 UPDATE。

该文件似乎表明，提交读仍然受到故障，应予以重审。

可以将 READ COMMITTED 设置为以与 SERIAZLIZABLE 相同的原子性无限期重试吗？

Answer 1

可以将 READ COMMITTED 设置为以与 SERIAZLIZABLE 相同的原子性无限期重试吗？

不。

READ COMMITTED不重试。也不行SERIALIZABLE。该应用有望重试交易遭受死锁，系列化故障等

文档中的描述非常具有误导性，我将在文档列表中提出。PostgreSQL 根本READ COMMITTED不像其他数据库（例如 Oracle）那样“重新开始” 。相反，它一直等到它等待提交或回滚的行。如果另一个 tx 提交 PostgreSQL读取更新的行，检查它是否仍然匹配任何WHERE子句或其他谓词，然后继续执行。细节有点神秘，请参阅EvalPlanQual来源。

在任一READ COMMITTED或SERIALIZATION应用程序中都应该能够重新发出事务。READ COMMITTED事务可能会以重试成功的方式失败，包括：

• 由于锁升级、锁排序问题等导致的死锁检测
• 管理查询取消请求
• 数据库的管理关闭/重启
• 数据库意外崩溃/重启
• 连接中断
• ... 等等

SERIALIZABLE 只是增加了一些失败案例。

编写好的应用程序将处理查询失败并重新发出事务。