PostgreSQL 15中已提交旧事务如何影响正在执行的事务？

你的假设完全成立 #

当长事务txnA触发默认的max_pred_locks_per_transaction=64限制时，PostgreSQL会自动降级谓词锁粒度——从行/索引级锁退化为表级锁。哪怕txnA未操作txnB涉及的表，表级谓词锁会将整个表标记为序列化检查的范围，导致后续txnB类事务在执行序列化依赖分析时，错误构建出与已提交旧事务的冲突关系，进而持续触发serialization_failure。

已提交旧事务影响当前事务的关键原因 #

在SERIALIZABLE隔离级别下，PostgreSQL依赖全局事务依赖图保证序列化一致性。锁粒度降级为表级后：

• 依赖判断范围从精准的行/索引扩大到整个表
• 长事务txnA持续持有表级锁期间，序列化管理器无法准确区分真实冲突事务，误将已提交旧事务纳入冲突链
• 旧事务的提交记录被错误关联到当前事务的序列化检查中，导致即使旧事务已提交15分钟，后续操作仍触发冲突

其他可能的触发场景 #

• 谓词锁内存耗尽触发磁盘存储：共享内存中的谓词锁池耗尽时，PostgreSQL会将锁信息写入磁盘。磁盘锁的清理机制滞后，会导致旧事务锁残留，干扰后续事务检查。
• 长事务锁持有时间过长：txnA持续运行期间，表级锁会阻止序列化管理器正确清理旧事务的依赖标记，直到txnA终止。
• 序列化算法误判：锁粒度降级后，序列化检查算法无法精准识别事务间的实际依赖，误将无关联的已提交事务标记为冲突源。

解决与优化建议 #

• 调大max_pred_locks_per_transaction参数（例如设置为256或更高），避免长事务触发锁粒度降级。
• 拆分或优化长事务txnA，缩短其运行时间，减少谓词锁持有周期。
• 监控共享内存使用情况，确保有足够内存容纳谓词锁，避免触发磁盘存储逻辑。
• 出现持续序列化失败时，优先终止长事务txnA，验证表是否能恢复正常更新。

内容的提问来源于stack exchange，提问作者Jake Biesinger