PostgreSQL及MVCC数据库中双事务是否会因死锁/序列化错误均回滚？

好问题！这确实是编写重试逻辑时非常关键的细节，搞清楚能帮你避开无限循环的坑。咱们分开两种错误场景来聊：

1. 死锁场景：绝不会出现双事务同时失败 #

PostgreSQL（以及大多数实现死锁检测的MVCC数据库）的死锁检测器会定期扫描事务等待图，一旦发现循环等待的死锁情况，它会主动挑选一个**「代价较小」的事务**作为牺牲品回滚（通常选执行时间更短、修改数据更少的那个），抛出deadlock_detected错误，而另一个事务会继续执行，不会被中断。

所以死锁情况下，你完全不用担心两个事务同时失败，只会有一个需要重试。

2. 序列化错误（Serializable隔离级别）：极端情况下可能出现双失败，但非常罕见 #

当你使用SERIALIZABLE隔离级别时，数据库会在事务提交前检查：是否存在一个合法的串行执行顺序，能让所有并发事务的结果和实际执行一致。如果不存在，就会抛出serialization_failure错误并回滚当前事务。

通常的情况是：事务A先提交成功，事务B在提交时检测到和A的操作无法序列化，于是B回滚。但在极端的并发场景下（比如两个事务几乎同时提交，且互相存在序列化冲突），有可能两个事务都在提交阶段检测到冲突，最终双双回滚。不过这种情况非常少见，更多是理论上的可能性，实际生产中遇到的概率很低。

对你重试逻辑的建议 #

• 针对死锁错误：因为只有单个事务失败，立即重试是安全的，不会陷入循环。
• 针对序列化错误：虽然双失败概率低，但为了保险起见，重试前最好加一个随机短延迟（比如10-100ms），避免两个事务立即重试后再次触发相同的冲突，进入无限循环。另外，也可以给重试加次数上限，防止极端情况导致的无限重试。

内容的提问来源于stack exchange，提问作者Lesly O