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

Jim*_*Bob 2 postgresql performance version-control serialization postgresql-performance

PostgreSQL Concurrency With MVCC 页面上,它说:

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

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

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

Cra*_*ger 5

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

不。

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

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

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

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

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

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