现在，我阅读了有关“Transaction ID Wraparound”的文档，但有一些我真的不明白，文档是以下网址 http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html#VACUUM-FOR-WRAPAROUND
23.1.4. 防止事务 ID 环绕失败
PostgreSQL 的 MVCC 事务语义依赖于能够比较事务 ID (XID) 编号：插入 XID 大于当前事务 XID 的行版本是“在未来”并且不应该对当前事务可见。但是由于事务 ID 的大小有限（32 位），长时间运行（超过 40 亿个事务）的集群会遭受事务 ID 回绕：XID 计数器回绕为零，并且突然之间，在过去似乎在未来——这意味着它们的输出变得不可见。简而言之，灾难性的数据丢失。（实际上数据仍然存在，但如果您无法获取它，那将是一种冷酷的安慰。）为了避免这种情况，有必要每 20 亿次事务至少对每个数据库中的每个表进行一次清理。
我不明白“将遭受交易 ID 环绕：XID 计数器环绕为零，突然之间过去的交易似乎在未来——这意味着它们的输出变得不可见”
有人可以解释一下吗？为什么在数据库遭受事务 ID 环绕之后，过去的事务会出现在未来？简而言之，我想知道 PostgreSQL 在事务 ID 被 autovacuum wraparound 后是否会出现“数据丢失”的情况。
就我个人而言，我们可以使用 txid_current() 函数获取当前事务 ID，其输出为 64 位，不会循环。所以我认为知道为 xmin 的元组的插入事务 ID 会比得到的 xid 神经更大通过 txid_current() 函数。除非您在关闭 PostgreSQL 服务器后使用 pg_resetxlog 重置重置事务 ID。我对吗 ？谢谢
他们没有。引用的文本只是解释了为什么 postgres 需要使用模 2 31算术（这意味着只要旧事务足够早地“冻结”，事务就可以回绕）：
再具体一点：
或包裹 XID 会导致事情破裂。为了防止这种情况，postgres 将开始发出警告，并最终关闭并在必要时拒绝启动新事务：
换句话说，“过去的交易似乎在未来”和“数据丢失”完全是理论上的，在实践中不会由交易 ID 环绕引起。
您粘贴的块似乎回答了这个问题。这完全取决于用于隐藏“未来”交易的逻辑。
事务 ID (XID) 计数器限制为32 位，如果它达到下一个数字，而不是替换旧的最大事务，它会从零开始。
好吧，现在它是零，所以 PostgreSQL 隐藏了所有大于 0 的事务。所以即使事务#2,147,483,633 发生在 20 秒前，PostgreSQL 认为它不会再发生 2,147,483,633 个事务。