postgresql - 子事务 ID 消耗哪些资源？

Question

The PostgreSQL wiki建议使用重试循环实现 UPSERT 的方法。此解决方案中隐含使用“子事务 ID”。在维基文章中有以下警告:

The correct solution is slow and clumsy to use, and is unsuitable for significant amounts of data. It also potentially burns through a lot of subtransaction IDs - avoiding burning XIDs is an explicit goal of the current "native UPSERT in PostgreSQL" effort.

使用“很多子事务 ID”的后果是什么？我真的不知道什么是子交易 ID - 这只是一种对嵌套交易进行编号的方式，是否暗示这些数字可能会用完？

Answer 1

资源是 32 位的 XID 事务计数器本身，引擎使用它来了解表中行的版本是否与“旧”事务(已提交或已滚动)相关联返回)或尚未提交的交易，以及它在任何给定交易中是否可见。

以超高速率增加 XID 会产生或增加出现事务 ID 环绕问题的风险。最坏的情况是此问题升级为数据库自动关闭以避免数据不一致。

避免事务 ID 回绕的是例行清理。这在 Preventing Transaction ID Wraparound Failures 下的文档中有详细说明。 .

但是 autovacuum 是后台任务，不会妨碍前台事件。除其他外，它会取消自身而不是锁定其他查询。有时，它可能会落后很多。

我们可以想象一个最坏的情况，即前台数据库事件增加 XID 值的速度如此之快，以至于 autovacuum 没有时间在新事务或子事务声明这些 XID 值之前卡住具有“旧 XID”的行，这是 PostgreSQL 无法处理的情况。

也可能是这些前台事务在发生这种情况时仍未提交，因此即使是激进的真空也无能为力。

这就是为什么程序员应该谨慎对待使此事件更有可能发生的技术，例如在巨大的循环中打开/关闭子事务。

范围大约是 20 亿笔交易，但这是系统设计时无法达到的限制，但随着我们的硬件能力和我们对数据库的要求不断增加，这将成为问题。