PostgreSQL 15高负载下跨库Serializable事务冲突异常求助

核心结论 #

跨库的Serializable事务确实可能在特定场景下引发冲突，根源在于PostgreSQL的Serializable SSI（Serializable Snapshot Isolation）实现依赖全局事务ID（XID）和全局事务依赖跟踪，而非严格按数据库隔离冲突检测逻辑，再加上高负载+长时长Serializable事务的放大效应，就会出现你遇到的跨库冲突现象。

具体原因拆解 #

1. SSI的全局依赖跟踪特性
   PostgreSQL的Serializable隔离级基于SSI实现，需要在整个实例范围内跟踪所有事务的读写依赖关系，判断是否存在会导致串行化异常的循环依赖——而事务ID（XID）是全局唯一的，不属于某个单独数据库。
   虽然理论上跨库事务不会访问共同的数据库对象，本不应产生读写依赖，但当存在一个长时间运行的Serializable事务时，它会持续持有一个旧的全局快照，导致SSI的全局依赖检测逻辑被拉长，覆盖到更早的全局事务记录。

2. 长事务的放大作用
   你提到的那个运行2小时的长事务是关键：

• 它会持续占用全局事务快照中的旧XID范围，使得其他库的短事务在进行冲突检测时，需要比对的全局事务历史被大幅拉长；
• 高负载下CPU 100%会导致事务提交、状态同步的延迟，SSI的依赖图构建可能出现偏差，错误地将跨库的旧事务（比如你提到的已提交1小时55分的事务）判定为与当前事务存在读写依赖，进而触发Serializable冲突。

3. 错误信息对应的场景
   你遇到的两类错误都是SSI中循环依赖检测的典型表现：

ERROR: could not serialize access due to read/write dependencies among transactions
  Detail: Reason code: Canceled on identification as a pivot, with conflict out to old committed transaction 61866959.

PSQLException: ERROR: could not serialize access due to read/write dependencies among transactions
  Detail: Reason code: Canceled on conflict out to old pivot 61940806.

• Canceled on identification as a pivot：当前事务被判定为引发循环依赖的核心事务（pivot），因此被取消；
• Canceled on conflict out to old pivot：当前事务与一个旧的pivot事务存在依赖冲突，而这个旧事务的范围被长事务的快照意外拉长到了跨库的事务记录。

验证与解决方向 #

• 长事务结束后所有库恢复正常，完全符合上述逻辑：长事务释放了旧的全局快照，SSI的依赖检测范围回到正常区间，跨库的误判不再发生；
• 优化建议：尽量避免长时间运行的Serializable事务，必要时拆分为短事务；高负载下监控全局XID的使用情况，确保XID冻结操作正常执行；对只读事务严格使用SET TRANSACTION READ ONLY，帮助PostgreSQL跳过部分SSI冲突检测逻辑。

内容的提问来源于stack exchange，提问作者Eduard Wirch