PostgreSQLXID与virtualXID区别

    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 源码定义如下：

事务号类型定义：

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 级别的。

图中第一个红色圈中部分就是全局的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列，我们可以清晰的看到。

定义如下：

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。