PostgreSQL 是如何防止事务 ID 回卷（Transaction ID Wraparound的？

知识点图片

PostgreSQL（简称 PG）防止事务 ID 回卷（Transaction ID Wraparound）的核心机制是“冻结（Freeze）”机制，并依靠后台的 Autovacuum（自动清理） 进程强制执行。

要理解这个机制，我们需要从问题本身出发，逐步了解 PG 的解决方案。

1. 为什么会发生回卷？（问题的本质）

PostgreSQL 使用 MVCC（多版本并发控制） 来处理并发。每一行数据（Tuple）都有两个内部标记：

xmin：插入该行的事务 ID。
xmax：删除/更新该行的事务 ID。

PG 的事务 ID（XID）是一个 32 位的无符号整数，最大值约为 42 亿（ $2^{32}$ ）。
PG 将这 42 亿个 ID 分为两半：

过去的 21 亿：被认为是旧事务（对其可见）。
未来的 21 亿：被认为是新事务（对其不可见）。

灾难场景：随着系统不断运行，XID 不断增加，当达到 42 亿上限后，它会回卷（Wrap around）重新变成 3（0、1、2 是保留 XID）。这时，原本非常老的数据（比如 XID=500 插入的数据），在新的 XID（比如 XID=3）看来，变成了“来自未来的数据”，从而导致所有老数据瞬间变为不可见，这就等同于严重的数据丢失。

2. 核心解决方案：事务冻结（Freeze）

为了防止回卷，PostgreSQL 引入了“冻结（Freeze）”的概念。

它的基本思想是：如果一行数据已经足够老，老到所有并发事务都已经结束了，我们就不再用具体的 XID 去判断它的可见性，而是给它打上一个“冻结”标记。

底层实现：在早期版本中，PG 会把数据的 xmin 改为特殊的保留 XID（FrozenTransactionId = 2）。在现代版本（PG 9.4+）中，为了优化性能，PG 直接在行头部信息（Tuple Header）中设置一个标志位（Hint Bit），称为 HEAP_XMIN_FROZEN。
效果：任何事务在读取数据时，如果看到这个“冻结”标记，就会无条件地认为这行数据是对所有人可见的旧数据，从而跳过正常的 XID 比较。

这样，随着老数据被不断“冻结”，数据库中实际存在的、未冻结的旧 XID 就永远不会跨越 21 亿的界限。

3. 执行者：防回卷自动清理（Anti-Wraparound Autovacuum）

“冻结”动作是由 VACUUM 进程完成的。为了确保冻结操作一定会被执行，PG 设计了严密的防线：

防线一：日常清理（Normal Vacuum）

正常的 autovacuum 或手动 VACUUM 在清理死元组（Dead Tuples）时，如果顺便发现有些存活的元组的 XID 年龄大于 vacuum_freeze_min_age（默认 5000 万），就会顺手将它们冻结。

防线二：强制防回卷清理（Autovacuum to prevent wraparound）—— 最关键的机制

如果一张表很少被更新或删除，常规的 autovacuum 可能根本不会去碰它。为了防止这张表里的 XID 老化导致回卷，PG 设置了一个硬性阈值：autovacuum_freeze_max_age（默认 2 亿）。

强制触发：当某张表中最老的未冻结 XID 的年龄达到 2 亿时，PG 的 Autovacuum Launcher 会无视用户的任何设置（即使你在 postgresql.conf 中把 autovacuum 设为 off），强制启动一个特殊的 Vacuum 进程。
不可取消：这个防回卷的 Vacuum 进程非常霸道，无法被轻易取消（如果被 kill 掉，系统马上又会重启它）。它会扫描全表（结合可见性映射表 Visibility Map 进行优化），将所有老于阈值的数据全部冻结。

4. 终极防线：停机保护（Failsafe & Read-Only Mode）

如果因为某些原因（比如 I/O 极慢、长时间持有锁的长事务阻塞了 Vacuum、或者参数设置不当），导致防回卷 Vacuum 一直未能成功完成，XID 继续疯狂增长，PG 还有最后的保护机制：

疯狂警告期（Warning phase）：
当最老的 XID 距离 21 亿的灾难点还剩 4000 万（旧版本是 1000 万）个事务时，PG 会在日志中疯狂输出警告信息：
WARNING: database "mydb" must be vacuumed within 39999999 transactions
此时 DBA 必须立刻介入排查 Vacuum 失败的原因。
强制只读停机期（Shutdown phase）：
如果警告被无视，当距离灾难点只剩 300 万（旧版本是 100 万）个事务时，为了彻底保护数据不丢失，PostgreSQL 会拒绝执行任何新的写入事务（直接报错）。
ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb"
- 恢复方法：此时数据库已经无法正常使用。DBA 必须将数据库启动为单用户模式（Single-user mode），并手动执行 VACUUM FREEZE，等待漫长的冻结过程结束后，数据库才能恢复正常工作。

5. 现代 PostgreSQL 的优化（PG 14+）

虽然上述机制很完善，但防回卷全表扫描（Aggressive Vacuum）会消耗大量 I/O。因此 PG 也在不断进化：

Visibility Map (VM)：PG 维护了一个可见性映射表，用来记录哪些数据块（Page）里的数据已经全部被冻结了。防回卷 Vacuum 会直接跳过这些块，极大地减少了 I/O。
64 位 XID（PG 14 引入）：PG 14 在内存底层开始引入 64 位的事务 ID（FullTransactionId），虽然写入磁盘的 tuple header 里为了节省空间仍然是 32 位，但这一底层改进使得防回卷机制的管理更加平滑，并引入了 vacuum_failsafe_age 机制，在极其危急的情况下，Vacuum 会绕过所有索引清理和成本延迟（Cost Delay），以最快速度裸跑全表冻结。

总结

PostgreSQL 防止事务 ID 回卷的机制可以概括为：利用 VACUUM 进程扫描数据，通过将老数据的 XID 标记为“冻结（Frozen）”使其脱离 32 位轮回。依靠 autovacuum_freeze_max_age 强制触发清理，并在极度危险时通过“拒绝写入（只读停机）”作为最后的数据保护底线。

播面