PG的事务ID回卷逻辑

原创已于 2024-05-11 16:49:55 修改 · 732 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#数据库

于 2024-05-10 15:14:26 首次发布

PostgreSQL 专栏收录该内容

29 篇文章

订阅专栏

PG到目前为止使用的事务ID仍然是32位的，在内存计算时虽然已经使用64位事务ID，但是存储在页中tuple仍然使用32位事务ID，这就是说，事务ID回卷仍然是必须处理的问题。

所谓PG事务ID回卷，简单地说，就是在数据库频繁运行中，事务ID不断增加，32位的事务ID不够用了，怎么办？PG的处理方法，简单的说，就是在事务ID还没用完以前，把数据库中所有的tuple处理一遍，将以前的事务（不活跃的事务）修改的（包括插入）tuple中的事务ID改为2（或设置infomask），表示这个tuple对于以后的事务（不管是多少的事务ID）都是可见的，即freeze。

这样，当前事务达到2^32后，再从3开始(0、1、2保留做特殊事务ID)，就不会有什么问题了，即就不会导致很旧的事务修改过的tuple不可见了。

这里有个隐含背景知识，就是PG内部读写tuple时，tuple中的事务ID，在当前事务ID之前 ，这个tuple对于当前事务才是可见的。

网上有一张图片，来说明“之前”、“之后”和回卷的概念，但是我觉得都没说明白，我来尝试理解一下，我觉得问题的关键是PG源码中比较事务ID的函数：

TransactionIdPrecedes() 和 TransactionIdFollows()

按照上面代码的算法，对于任何事物ID，例如100，如果另一个事务ID比它大，但是没有超过这个事务ID后的半圆，例如2^31+100，就认为是在它的后面，那么事务100的tuple，对事务2^31+100就是可见的。

按照上面代码的算法，对于任何事物ID，例如100，如果另一个事务ID比它大，还超过了事务ID后的半圆，例如2^31+101，就认为是在它前面，那么事务100的数据，对事务2^31+101就是不可见的。

这导致对任何事务ID，它只能看到它之前的 2^31 个事务的数据，而不是 2^32 个事务的数据，而且不同事务的可见事务集合也是不同的。

这种算法叫做 “模算数” （modulo-2^32 arithmetic）

这个和freeze有什么关系呢？

想象事务ID一直在增加，穿过圆心的线顺时针转动，每转动一个事务ID，就有一个事务ID变的不可见，要想不丢失这个事务ID的数据，就要对它的tuples做freeze，这一岂不是freeze太频繁了吗？

实际上，PG对于past部分的tuple，早就做了freeze了，例如下图，一般X之前的tuple已经freeze过了，而当前事务ID不断增加，每隔一段时间做一次freeze，将与当前事务ID有一定差值（5千万）的past tuple，做freeze。

并不是在穿过圆心的直线另一端，快到达某个事物ID时（未做freeze的tuple事务ID与当前事务ID差值已经非常大了），才对这个事物ID做freeze。

总结一下vacuum，最近看pgvector索引代码时，对vacuum有了新的理解，pgvector有个接口:hnswbulkdelete，是删除了表的一些记录后，做vacuum时，删除索引中对应条目用的。

PG删除记录时，不是真的删除，而是在tuple上标记删除，此时也不会删除对应的索引项，真的删除是vacuum时做的。

vacuum是以表为单位进行的，就是说最小可以只对一个表进行vacuum，它主要有两个工作：

1、删除 dead tuple

2、将记录设置frozen xid

这两个工作都有，lazy和eager两种模式，它们的触发条件不同，对系统的影响也不同。

1、lazy模式，删除dead tuple，跳过没有dead tuple的page（参考vm），对于有dead tuple的page，物理删除dead tuple和对应索引项，页内碎片整理。

2、eager模式，删除dead tuple，不会参考vm，直接重建一份表数据，从旧的表数据的page中逐个tuple拷贝，重建索引，表内碎片整理。它的触发条件就是用FULL VACUUM命令。

3、lazy模式，freeze，跳过没有dead tuple和所有tuple都已经freeze的page（参考vm），对其他page中的tuple设置frozen txid，但是又不是每个tuple都设置，只有xmin小于特定值的tuple才设置。

4、eager模式，freeze，跳过所有tuple都已经freeze的page（参考vm），对其他page中的tuple设置frozen txid，但是又不是每个tuple都设置，只有xmin小于特定值的tuple才设置。这里面还有个特殊情况，就是vacuum时有FREEZE选项，则用eager模式，但是并不是只有xmin小于特定值的tuple才设置frozen，而是所有小于当前事务ID的tuple都设置frozen。

触发条件：粗糙的说，当前事务ID与数据库中最小的（未freeze的）事务ID，的差达到一定值后，就会触发。这个“当前事务ID”是指OldestXmin ，“数据库中最小的事务ID”是指pg_database.datfrozenxid，差值是Vacuum_freeze_table_age。

5、autovacuum触发条件，既可以是事务ID的改变，也可以是dead tuple的比例的改变，也可以是新插入的tuple的比例达到一定阈值。

参考：

6.3. Freeze Processing :: Hironobu SUZUKI @ InterDB

postgresql - About "Transaction ID Wraparound" - Database Administrators Stack Exchange