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 源碼定義如下：

事務號類型定義：

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。