mysql xid_PostgreSQL XID与virtual XID区别

PG中事务号有两个概念,一个就是通常意义上的事务号transaction id。如tuple中的xmin,xmax等。另外一个意义是虚拟事务ID,即virtual transaction ID。那么这两个有

什么区别呢?

1.Transaction Id

它是用来标识事务的顺序的,类似于Oracle的LSN(Logical Sequence Number)。但是PG中的这个事务号是可以wrap的,也就是重复使用的。

PG定义此事务ID为32位长度。相当于4 billion。因为是重复使用的,所以首尾相接,构成一个环。那也就是说,对于任何一个事务ID,有2 billion的事务ID比自己old,

有2 billion的事务比自己new。另外有三个事务ID有特殊意义:”0”代表invalid 事务号,”1”代表bootstrap事务号,“2”代表frozen 事务,“3”代表最小的用户事务ID。

另外,1“和”2“也都是valid。frozen transaction id比任何事务都要old。PG用来解决事务号wrap问题,在事务号循环使用情况下,可能会出现新的事务号比老的事务号要小。

因此将老的事务号设置为”2”,表示是frozen transaction。frozen transaction id的动作由vacuum发起。具体介绍请我的另外一篇文章”PostgreSQL vacuum原理—vacuum揭秘“。

transaction id的产生受lwlock ”XidGenLock“保护,存放在ShmemVariableCache共享内存段中。

transaction id 源码定义如下:

da1eb926793242a398165576d0c41265.png

事务号类型定义:

e687e43d0e41f0dce505d4d96fde6ad7.png

2.Virtual Transaction Id

也就是通常所讲的虚拟事务ID。virtual transaction id 由两部分组成,backend process ID 号和local transaction id组成。

backend process ID号不是操作系统的进程ID,而是PG中用来标识进程序列号的ID。而local transansaction id也是用32位长度来表示。跟上面讲的transaction id的区别看名字就知道:是local和非local的差别。

也就是说这个local transaction id是每个backend 进程独有的。而上面第一部分讲的transaction id是全局的,即整个PG cluster 级别的。

3cb2d2579b31c15b085e482eac963ea5.png

图中第一个红色圈中部分就是全局的transaction id。而第二圈中的内容就是virtual transaction id。 backend id号和local transaction id用”/“符号分隔。

前面部分为backend id号,后面部分为local transaction id。第三个红色圈中部分为系统进程号。这里明显看到,virtual transaction id中的backend id号跟第三个红色圈中的pid是不同的。

pid是操作系统的进程号。virtual transaction id只有valid 和invalid之分。”0“表示为invalid,其它都是valid。另外,virtual transaction id 在数据库重起后,就会重新使用;但是在同一个backend id下会按顺序增长。

virtual transaction id的持有,都是ExclusiveLock,因为在一个进程私有空间内,不存在争用情况。这点上,跟transaction id是一样的,transaction id是全局独享的,因此也是ExclusiveLock。

从上面图中的mode列,我们可以清晰的看到。

定义如下:

5afa0f055f200aeef7385eb3f3027e54.png

3.总结

为什么PG会搞这么两个transaction id呢,用途和意义是什么呢?

我们知道,像类似于SELECT语句,并不会改变数据库;而DML语句会对数据库状态产生影响。因此这也就是为什么区别对待的原因。

transaction id属于permanent id,即永久ID。它的意义是指对数据库的更改序列,使得数据库从一种状态变成另外一种状态,而且状态的改变是持久的,可恢复,是一致性的。

这也符合的数据库理论ACID的要求。

而查询,实际上并不需要这种永久事务ID,只需要处理好MVCC,锁的获取和释放即可,因此virtual transaction id也就足够了。不需要去获取XidGenLock而产生transaction id,

从而提高数据库性能。另外,数据库也不会因为查询而导致transaction id快速wrap around。MVCC的处理是不需要transaction id值的。当查询时,获取当前每个活动进程的xmin和xmax值,

以此区间去对比每个tuple header中的xmin和xmax即可得到可见性snapshot。MVCC详细实现见”PostgreSQL MVCC 源码实现“。

另外获取的时机也有很大差别。PG的事务实现有三层,分别为top layer, middle layer 和bottom layer。virtual transaction id在top layer中获取。不管是查询,还是DML操作,每个

命令都有virtual transaction id。而transaction id是在bottom layer中获取的,只有真正涉及到数据修改时,才去获取。修改tuple后,会将transaction id的值存放到tuple header 中,

这也是我们通常讲的xmin或者xmax。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值