当前位置：首页 > news >正文

PostgreSQL数据库的事务ID和事务机制

news 2025/7/12 19:42:18

PostgreSQL后续简称PG。PG只读事务不会分配事务ID。为了在共享锁等情况下对事务进行标识，需要一种非持久化的事务ID，即虚拟事务ID，vxid。虚拟事务ID不需要把事务ID持久化到磁盘。因为事务ID是很宝贵的资源，简单的select语句不会申请事务ID。vxid由两部分组成：backendId 和backend本地计数器。查看如下：

BEGIN;
SELECT locktype,virtualxid,virtualtransaction,mode FROM pg_locks; -- 查看vxid
SAVEPOINT p1;
SELECT locktype,virtualxid,virtualtransaction,mode FROM pg_locks; -- 子事务的vxid不变
ROLLBACK;
SELECT locktype,virtualxid,virtualtransaction,mode FROM pg_locks;

vxid的backendId不是真正的进程号PID，也只是一个简单的递增的编号。
vxid的backendId和命令编号都是递增的。
子事务没有自己的vxid，他们用父事务的vxid。
vxid也有回卷，不过问题不严重，因为没有持久化，实例重启后vxid从头开始计数。

永久事务是指当发生数据变化的事务开始时，事务管理器会分配一个唯一事务号标识。后续事务指永久事务。事务号Transaction ID，txid，又叫xid，是32位无符号整型，总共可以存储 2³²=4294967296，42亿多个事务，范围为：0~2³²-1。同一个数据库中，存在的最旧和最新事务之间的年龄允许最大为2的31次方，约为20亿。其中xid：

0：InvalidXid，无效事务ID。
1：BootstrapXid，表示系统表初始化时的事务ID。最旧。
2：FrozenXid，冻结的事务ID，比任何普通的事务ID都旧。

正常事务号从3开始。在PostgreSQL 7.2之前，当32位事务ID用完时，必须dump然后恢复数据库。之后使用64位I的FullTransactionId，获取epoch和xid如下：

#define EpochFromFullTransactionId(x)	((uint32) ((x).value >> 32))
#define XidFromFullTransactionId(x)		((uint32) (x).value)

epoch是FullTransactionId右移32位，xid（TransactionId）是FullTransactionId对2³²取模。这相当于把32位的TransactionId看成“环”，循环重复使用；64位的FullTransactionId是一直递增的“线”，几乎取不完。事务启动后会执行内置txid_current函数，该函数会在上次事务加1后返回事务号。

-- PG12及以前用txid_current()。返回的为扩展xid，uint64。
SELECT pg_current_xact_id();
SELECT pg_current_xact_id_if_assigned(); -- 返回当前事务id-- 查看系统初始化时的事务ID
SELECT xmin,count(*) FROM pg_class WHERE xmin=1 GROUP BY xmin;SHOW TRANSACTION_ISOLATION; -- 查看事务隔离级别，默认read committed读已提交-- begin不会立即分配事务id，begin后的第一个非查询语句分配事务id
-- 当一个事务插入了一tuple后，会将事务的txid写入这个tuple的xmin
BEGIN; -- 开启事务
INSERT INTO t_test VALUES(1),(2);
SAVEPOINT my_save; -- 设定事务保存点
INSERT INTO t_test VALUES(3);
ROLLBACK TO my_save; -- 回滚到保存点状态，即不要3这个数字
COMMIT; -- 提交后只有1,2

事务ID对比的函数结构如下：

bool TransactionIdPrecedes(TransactionId id1, TransactionId id2)
{/** If either ID is a permanent XID then we can just do unsigned* comparison. If both are normal, do a modulo-2^32 comparison.*/int32        diff;if (!TransactionIdIsNormal(id1) || !TransactionIdIsNormal(id2))return (id1 < id2);diff = (int32) (id1 - id2);return (diff < 0);
}

函数的基本逻辑为：

TransactionIdIsNormal是判断id是否>=3(FirstNormalTransactionId)。
id1-id2结果溢出，即超过数据存储范围，为使在范围内，对数值加减模长2³²，比如2³¹减模长为-2³¹。
非正常事务比较：当id1=2，id2=100时，return(2<100)，结果为真，正常事务较新；当id1=100，id2=2时，return (100<2)，结果为假，正常事务较新。
正常事务比较：当id1=2³¹+99，id2=100，id1-id2=2³¹-1。int32可以存放，大txid较新；当id1=2³¹+100，id2=100，id1-id2=2³¹。超出int32范围，值为2³¹-2³²=-2³¹，小txid较新，相当于看不到id2；当id1=100，id2=2³¹+100，id1-id2=-2³¹。这没问题，int32刚好可以存放，大txid较新；当id1=100，id2=2³¹+101，id1-id2=-2³¹-1。超出int32范围，此时的值为-2³¹-1+2³²=2³¹-1>0，小txid较新，此时进入第1次回卷，即100大于2³¹+101了。
为了防止出现两者相差2³¹或2³¹-1，将两者差值限制在20亿。这样可以保证提前处理冻结，防止出现4的错误情况。

上面比较看出，当发生数值溢出时，txid大的事务看不见更小的txid事务。为了解决这个问题，pg将40亿事务id分成两半，一半事务是可见的，另一半事务是不可见的。

事务回卷的理解包括两个方面：

事务ID回卷是为了让事务ID有一个环的概念，这一圈用完了继续向前转，继续循环使用。每到达最大值2³²之后，事务ID从下一个3开始，只是事务ID的扩展epoch加1。
因为事务ID将环分成2半，一般可见，一般不可见。事务ID跨越超过一半说明事务ID就是回卷了，此时超过一半的那部分事务数据虽然存在但无法查到等效于丢失了。为了解决这个问题需要处理冻结事务ID的操作。保证事务ID不超过21亿（具体是2³¹-1）。冻结的事务ID都是可见的。

为了解决上面2的回卷问题，PG采用冻结的方式处理事务ID，相关配置参数：

vacuum_freeze_min_age：元组xmin比当前txid-该参数值的差更旧时，会进行freeze，也就是有元组年龄或表年龄超过该值后进行freeze。该参数最大值为20亿，最小值为2亿。
vacuum_freeze_table_age：表的年龄超过该值会进行aggressive vacuum。该参数最大值为20亿，最小值为1.5亿。如果为0，则每次扫描表都进行aggressive vacuum。
autovacuum_freeze_max_age：表的年龄超过该值强制执行autovacuum。该参数最小值为2亿，最大值为20亿。即经过autovacuum_freeze_max_age-vacuum_freeze_min_age的txid增长之后，表肯定会被强制进行一次freeze。因为autovacuum_freeze_max_age最大值为20亿，所以在两次freeze之间，txid的增长肯定不会超过20亿，这就保证了上文中所说的20亿原则。

每次表被freeze之后，会更新pg_class.relfrozenxid列为本次freeze的最大txid。该列保存对应表最近冻结的txid，意味着小于此值的txid均已被冻结。表的年龄为当前最新txid与relfrozenxid的差值。元组年龄其t_xmin与对应表relfrozenxid的差值。

查看全文

http://www.lryc.cn/news/416845.html