2. 程式人生 > >淺析Postgres中的並發控制(Concurrency Control)與事務特性(上)（轉）

淺析Postgres中的並發控制(Concurrency Control)與事務特性(上)（轉）

阿新 • • 發佈：2018-11-26
工作原理 abort 保持 text 我認 理解 刪除 heap 普通

這篇博客將MVCC講的很透徹，以前自己懂了，很難給別人講出來，但是這篇文章給的例子就讓人很容易的復述出來，因此想記錄一下，轉載給更多的人

轉自：https://www.cnblogs.com/flying-tiger/p/9567213.html

PostgreSQL為開發者提供了一組豐富的工具來管理對數據的並發訪問。在內部，數據一致性通過使用一種多版本模型（多版本並發控制，MVCC）來維護。這就意味著每個 SQL 語句看到的都只是一小段時間之前的數據快照（一個數據庫版本），而不管底層數據的當前狀態。這樣可以保護語句不會看到可能由其他在相同數據行上執行更新的並發事務造成的不一致數據，為每一個數據庫會話提供事務隔離。MVCC避免了傳統的數據庫系統的鎖定方法，將鎖爭奪最小化來允許多用戶環境中的合理性能。

使用MVCC並發控制模型而不是鎖定的主要優點是在MVCC中，對查詢（讀）數據的鎖請求與寫數據的鎖請求不沖突，所以讀不會阻塞寫，而寫也從不阻塞讀。甚至在通過使用革新的可序列化快照隔離（SSI）級別提供最嚴格的事務隔離級別時，PostgreSQL也維持這個保證。

今天我們就從基礎開始聊聊PostgreSQL內部的這一特性，聊聊MVCC和PostgreSQL中的事務特性。

這裏，我們先用一個表格展示PostgreSQL中的事務等級，在看到後面章節時可以翻回來看看。

技術分享圖片

1.基礎知識

1.1事務ID

當一個事務開始時，PostgreSQL中的事務管理系統會為該事務分配一個唯一標識符,即事務ID(txid).PostgreSQL中的txid被定義為一個32位的無符號整數，也就是說，它能記錄大約42億個事務。通常txid對我們是透明的，但是我們可以利用PostgreSQL內部的函數來獲取當前事務的txid：

postgres=# BEGIN;
BEGIN
postgres=# SELECT txid_current();
 txid_current 
--------------
          233
(1 row)

在所有的txid中，有幾個值是有特殊含義的：

txid = 0 表示 Invalid txid，通常作為判斷txid的有效性使用；
txid = 1 表示 Bootstrap txid，目前情況下，只在intidb的時候，初始化數據庫的時候使用
txid = 2 表示 Frozen txid，一般是在Vacuum時使用(在後面會提到)。

記住這樣一個假設：txid小的事務所修改的元組對txid大的事務來說，是可見的，反之則不可見。

技術分享圖片

1.2元組(tuple)結構

關於元組的結構能說的東西很多，我在這篇文章中也談到了一些。不過我們這裏不談那麽深。關於元組(tuple)原則上可以分成普通的元組和TOAST元組。這裏為簡化起見，我們就只談論簡單的元組。

簡單元組的結構圖如下：

技術分享圖片

在上圖中我們需要了解的和事務相關的結構是HeapTupleHeaderData結構，這個也就是一條元組的“頭”部分。

有幾個字段需要我們了解下：

  • t_xmin中保存的是插入這條元組的事務的txid

  • t_xmax中保存的是更新或者刪除這條元組的事務的txid。如果這條元組並沒有沒刪除或者更新，那麽t_xmax字段被設置為0，即該字段INVALID

  • t_cid中保存的是插入這條元組的命令的id。在一個事務中可能會有多個命令，事務中的這些命令會依次被編號(從0開始遞增)。對於如下的事務： BEGIN；INSERT ；INSERT END。那麽第一個INSERT的t_cid為0，第二個INSERT的t_cid為1.依次類推。

  • t_ctid中保存元組的標識符(即tid)。它指向該元組本身或者該元組的新“版本”。因為PostgreSQL對記錄的修改不會直接修改tuple中的用戶數據，而是重新生成一個tuple，舊的tuple通過t_ctid指向新的tuple。如果一條記錄被修改多次，那麽該記錄會存在多個“版本”。各版本之間通過t_ctid串聯，形成一個版本鏈。通過這個版本鏈，我們就可以找到最新的版本了。實際的t_ctid是一個二元組(x,y).其中x(從0開始編號)代表元組所在的page，y(從1開始編號)表示在該page的第幾個位置上。

1.3元組(tuple)的INSERT/DELETE/UPDATE操作

上面說到PostgreSQL中對記錄的修改不是直接修改tuple結構，而是重新生成一個tuple，舊的tuple通過t_ctid指向新的tuple。那麽這裏我們依次解釋INSERT/DELETE/UPDATE是如何實現的。

我們先上一個簡圖，這裏面的page header，line pointer這些這裏談論無關的結構我就不畫出來了。我們重點關註tuple在page中的位置關系。

技術分享圖片

1.3.1 INSERT操作

INSERT操作最簡單，直接將一條元組放進對應的page裏面即可。如下：

技術分享圖片

這裏我們假設

  • 1.該表在執行插入前為空

  • 2.txid為99的事務插入了該元組==> Tuple_1。

於是在Tuple_1中我們可以看到：

  • t_xmin被設置為了99，也就是事務的txid，99.

  • t_xmax被設置為了0，因為該元組還沒有被更新或者刪除

  • t_ctid被設置為了0，很顯然，它是被事務的第一條命令插入的

  • t_ctid被設置為了(0,1)，這是這個表的第一個元組，因此它被放置在第0 page的第1個位置上。

如何從數據庫外部來驗證呢？PostgreSQL提供了一個插件：pageinspect

我們可以像下面那樣去查看數據庫頁面上的信息：

postgres=# CREATE EXTENSION pageinspect;
CREATE EXTENSION
postgres=# CREATE TABLE tbl (data text);
CREATE TABLE
postgres=# INSERT INTO tbl VALUES(‘A‘);
INSERT 0 1
postgres=# SELECT lp as tuple, t_xmin, t_xmax, t_field3 as t_cid, t_ctid 
                FROM heap_page_items(get_raw_page(‘tbl‘, 0));
 tuple | t_xmin | t_xmax | t_cid | t_ctid 
-------+--------+--------+-------+--------
     1 |     99 |      0 |     0 | (0,1)
(1 row)

1.3.2 DELETE操作

上面說過了，PostgreSQL中的刪除操作只是在邏輯上“刪除了”元組，實際上該元組依然留存在數據庫的存儲頁面中，只是對該元組進行了一些處理，使得其在查詢中變得“不可見”。

假設我們在txid為111的事務中將上面插入的元組進行刪除時，其結果如下：

技術分享圖片

我們可以看到，Tuple_1元組的t_xmax字段被修改了，被改成了111，即刪除Tuple_1的事務的txid。

當txid為111的事務被提交時，Tuple_1就成了無效的元組了，成為“dead tuple”。

從圖上可以看到，這個Tuple_1依然殘留在數據庫的頁面上。隨著數據庫的運行，可以預見，這種“dead tuple”會越來越多。他們，會在運行VACUUM命令時被清理掉，有關VACUUM不是我們這次討論的重點，這裏略去。

1.3.3 UPDATE操作

相對於前面兩個操作，UPDATE顯得稍微復雜一點。根據我們上面所說，PostgreSQL對記錄的修改不會直接修改tuple中的用戶數據。PostgreSQL對UPDATE的處理是先刪除舊數據，後增加新數據。“翻譯”過來就是將要更新的舊tuple標記為DELETE，然後再插入一條新的tuple。

同樣地，我們假設在txid為99的事務中插入一條記錄，並且在txid為100的事務中被先後更新2次。過程如下：

技術分享圖片

根據我們提到的"先刪除舊數據，後增加新數據"的原則，當執行txid為100的事務中的第一條UPDATE命令時，操作分為兩步：

  • 刪除舊元組Tuple_1：設置Tuple_1的t_xmax值為當前事務的txid；

  • 新增新元組Tuple_2：設置Tuple_2的t_xmin，t_xmax，t_cid，t_ctid；設置Tuple_1的t_ctid指向Tuple_2

即：

對於Tuple_1：

t_xmax = 100;
t_ctid :  (0,1) => (0,2)

對於Tuple_2：

t_xmin = 100;
t_xmax = 0;
t_cid = 0;
t_ctid = (0,2)

同理，當執行txid為100的事務中的第二條UPDATE命令也是如此：

對於Tuple_2：

t_xmax = 100;
t_ctid :  (0,2) => (0,3)

對於Tuple_3：

t_xmin = 100;
t_xmax = 0;
t_cid = 1;
t_ctid = (0,3)

當txid為100的事務被提交時，Tuple_1和Tuple_2就成了“dead tuple”，反之，如果該事務被abort，則Tuple_2和Tuple_3就成了“dead tuple”。

說了以上這些，大家應該對這些操作在數據庫內部的實現有一個粗略的理解。同時，大家可能對這個ctid很好奇。這是個標記tuple所在位置的標記。那麽問題來了，tuple插入的位置是如何選定的？完全是按照順序存放麽？如果是那樣，我覺得可能直接記錄tuple在頁面內部的偏移就好了。問題就在於這個位置的選定是有"技術"的，PostgreSQL內部有一個稱為FSM的機制，即Free Space Map。通過它發現一個表的各個頁面的空余空間，從而決定放在那裏比較好。具體的不多說，有興趣的可以通過PostgreSQL的另一個插件pg_freespacemap來探究一下。

postgres=# CREATE EXTENSION pg_freespacemap;
CREATE EXTENSION

postgres=# SELECT *, round(100 * avail/8192 ,2) as "freespace ratio"
                FROM pg_freespace(‘accounts‘);
 blkno | avail | freespace ratio 
-------+-------+-----------------
     0 |  7904 |           96.00
     1 |  7520 |           91.00
     2 |  7136 |           87.00
     3 |  7136 |           87.00
     4 |  7136 |           87.00
     5 |  7136 |           87.00
....

有了上面的這些基礎，我們就可以繼續討論一些較為深入的內容了。

2.MVCC基礎

2.1 事務提交日誌(commit log)

PostgreSQL采用的日誌主要有XLOG和CLOG,即事務日誌和事務提交日誌。XLOG是一般的日誌記錄，即通常意義上所認識的日誌記錄，它記錄了事務對數據更新的過程和事務的最終狀態。CLOG在一般的數據庫教材上是沒有提及的，其實CLOG是XLOG的一種輔助形式，記錄了事務的最終狀態。因為每一條XLOGH誌記錄相對較大，如果需要通過日誌判斷一個事務的狀態，那麽使用CLOG比使用XLOG要髙效得多。同時CLOG占用的空間也非常有限，因此它被存儲在共享內存中，可以快速地讀取。

下面我們就來看看clog的工作原理及其維護過程。

首先，在CLOG中，PostgreSQL定義了四個事務狀態：

IN_PROGRESS,
COMMITTED,
ABORTED,
SUB_COMMITTED.

除了最後一個狀態，其它的狀態都是“人如其名”，不多說。而SUB_COMMITTED針對的是子事務，這裏先不討論太多。

由於存儲在共享內存中，CLOG是以8KB大小的page存儲的。在CLOG的頁面內部事務狀態是以類似"數組"的形式存儲的。其中"數組"的下標就是事務的ID，"數組"中的值即為對應下標的事務的當前狀態。由於CLOG只記錄事務的4個狀態，因此，只需要2個bit就可以表示，即一個字節可以表示4個事務狀態。在一個CLOG page(8KB)中,可以表示8K*8b/2b=32K=2^15條CLOG記錄。

下面上例子：

技術分享圖片

在T1時刻：txid為200的事務提交了，那麽在CLOG中txid為200的事務的狀態從IN_PROGRESS裝換為COMMITTED。

在T2時刻：txid為201的事務abort了，那麽在CLOG中txid為201的事務的狀態從IN_PROGRESS裝換為ABORTED。

整個CLOG就這樣一直追溯著事務系統中所有事務的狀態。如果有新的事務則直接在"數組"後面添加。當當前頁面(8KB大小)已經存滿時，則增加一個新的page進行記錄。

當PostgreSQL數據庫shutdown或者當進行checkpoint時，CLOG中的數據會被寫回到pg_clog目錄下。打開pg_clog目錄，我們會發現一些命名為0000,0001之類的文件。這些即為CLOG文件。這些文件的最大的size為256KB。也就是說，一個文件最多可以存儲256KB/8kB=32個CLOG。如果當前有8個CLOG，那麽0000文件就可以存下來。而如果當前有35個CLOG，那麽就需要0000,0001兩個文件來存儲，以此類推。

而當PostgreSQL數據庫啟動的時候，pg_clog文件夾下的CLOG記錄又會被讀到共享內存中。

2.2 事務快照(Transaction Snapshot)

終於要說到事務快照了。

事務快照我認為是一個很形象的詞，很容易從字面上理解它的意味。所謂"快照"，就是拿著照相機"哢嚓"一聲記錄下當前瞬間的信息，在按下快門後所發生的變化我們統統無法察覺，即invisible。

同樣地，事務快照就是當某一個事務執行期間，記錄的某一個時間點上哪些事務是active，所謂active，就是說這個事務要麽在執行中(in progress)，要麽還沒有開始。

PostgreSQL有內置的函數可以獲取當前的數據快照：txid_current_snapshot()函數
通過該函數可以獲取當前的快照，但是快照信息解讀起來需要費一點腦筋。

postgres=# SELECT txid_current_snapshot();
 txid_current_snapshot 
-----------------------
 100:104:100,102
(1 row)

上面的數據快照是這樣一個數字序列構成: xmin:xmax:xip_list

下面我來一一介紹各個字段的意義。

  • xmin

最早的active的事務的txid，即txid值最小的active事務；所有txid小於該值的事務，如果1.狀態為commited則為visible，2.狀態aborted則為dead，

  • xmax

第一個還未分配的txid，所有txid大於該值的事務在快照生成時尚未開始，即不可見

  • xip_list

快照生成時所有active的事務的txid。

對照上面的解釋，我們來兩個有代表性的例子吧：

技術分享圖片

  • 對於(a)：

txid小於100的事務都不是active的；

txid大於等於100的事務都是active的。

  • 對於(b)

txid小於100的事務都不是active的；

txid大於等於104的事務都是active的；

txid為100和102都是active的，101和103都不是active的。

那麽我們疑惑了，我們花這麽多篇幅去判斷一個事務是不是active有什麽意義呢？

下面來了。

在PostgreSQL中，當一個事務的隔離級別是READ COMMITTED時，在該事務中的每個命令執行之前都會重新獲取一次snapshot，而如果一個事務的隔離級別是REPEATABLE READ或者SERIALIZABLE時，該事務只在第一條命令執行時獲取snapshot。

記住以上的差別，正是以上的差別引起tuple的可見性的差別，從而實現不同的隔離級別。

還是來一張圖來解釋上面的話吧。

技術分享圖片

我們假設上面的三個事務依次執行，其中Transaction_A 和Transaction_B的隔離級別都是READ COMMITTED,Transaction_C的隔離級別是REPEATABLE READ。我們分時間段T1~T5來解釋：

T1

Transaction_A開始並執行第一條命令，此時獲取txid和snapshot。事務系統給Transaction_A分配txid為200，並獲取當前快照為 200:200：

T2

Transaction_B開始並執行第一條命令，此時獲取txid和snapshot。事務系統給Transaction_B分配txid為201，並獲取當前快照為 200:200：，因為Transaction_A正在執行中，所以Transaction_B無法看到Transaction_A中的修改。

T3

Transaction_C開始並執行第一條命令，此時獲取txid和snapshot。事務系統給Transaction_C分配txid為202，並獲取當前快照為 200:200：，因為Transaction_A正在執行中，所以Transaction_C無法看到Transaction_A和Transaction_B中的修改。

T4

Transaction_A進行了commit。事務管理系統刪除了Transaction_A的信息。

T5

Transaction_B和Transaction_C分別執行它們的SELECT命令。

此時，Transaction_B獲取一個新的snapshot(因為它的隔離級別是READ COMMITTED)，該snapshot為 201:201：。因為Transaction_A的已經提交。Transaction_A對Transaction_B可見。

同時，由於Transaction_C的隔離級別是REPEATABLE READ，它仍然使用第一條命令執行時獲得的snapshot 200:200 ，因此Transaction_A和Transaction_B仍然對Transaction_C不可見。

2.3元組可見性規則

所謂"元組可見性(Tuple Visibility)"的規則就是利用：

1.tuple中的t_xmin和t_xmax字段；
2.clog
3.當前的snapshot

來判斷一個tuple對當前事務中的執行語句是可見還是不可見。所謂可見與不可見就是說當前命令在處理時是否要處理該tuple。
還是為了簡便起見，我們回避了子事務和有關t_ctid的問題。只討論最簡單的情形。

我們選取十條規則並將他們分為三類進行說明。

1. t_xmin的狀態為ABORTED

我們知道t_xmin是一個tuple被INSERT時的事務txid。如果該事務的狀態為ABORTED，說明該事務被取消，那麽理所當然該事務所INSERT的tuple自然是無效並且是不可見的。所以Rule1即為：

Rule 1: If Status(Tuple.t_xmin) = ABORTED ? Tuple is Invisible

2. t_xmin的狀態為IN_PROGRESS

如果一個tuple的t_xmin的狀態為IN_PROGRESS，那麽很大可能它是不可見的。

因為：

如果這個tuple是其它事務(非當前事務)所插入的，那麽這個tuple顯然是不可見的，因為這個tuple還未提交(postgreSQL不支持讀未提交)。

Rule 2: If Status(t_xmin) = IN_PROGRESS && t_xmin ≠ current_txid ? Tuple is Invisible

如果這個tuple是當前事務提交的，並tuple的t_xmax值不是0，即該tuple是由當前事務插入，但是被當前事務UPDATE或者DELETE過了，因此，顯然是不可見的。

Rule 3: If Status(t_xmin) = IN_PROGRESS && t_xmin = current_txid && t_xmax ≠ INVAILD ? Tuple is Invisible

反之，如果這個tuple是當前事務提交的，並tuple的t_xmax值是0，說明這個tuple是由當前事務插入並且並沒有被修改過，所以，它是可見的。

Rule 4: If Status(t_xmin) = IN_PROGRESS && t_xmin = current_txid && t_xmax = INVAILD ? Tuple is Visible

3. t_xmin的狀態為COMMITTED

和上面的相反，如果一個tuple的t_xmin的狀態為COMMITTED，那麽很大可能它是可見的。

先把規則列出來，後面再解釋。

Rule 5: If Status(t_xmin) = COMMITTED && Snapshot(t_xmin) = active ? Tuple is Invisible

Rule 6: If Status(t_xmin) = COMMITTED && Snapshot(t_xmin) ≠ active && (t_xmax = INVALID || Status(t_xmax) = ABORTED) ? Tuple is Visible

Rule 7: If Status(t_xmin) = COMMITTED && Status(t_xmax) = IN_PROGRESS && t_xmax = current_txid ? Tuple is Invisible

Rule 8: If Status(t_xmin) = COMMITTED && Status(t_xmax) = IN_PROGRESS && t_xmax ≠ current_txid ? Tuple is Visible

Rule 9: If Status(t_xmin) = COMMITTED && Status(t_xmax) = COMMITTED && Snapshot(t_xmax) = active ? Tuple is Visible

Rule 10: If Status(t_xmin) = COMMITTED && Status(t_xmax) = COMMITTED && Snapshot(t_xmax) ≠ active ? Tuple is Invisible

Rule5是比較顯然的，對於一個tuple，插入它的事務已經提交(COMMITED)，並且該事務在當前的snapshot下是active的，說明該事務對當前事務中的命令來說是 in progress 或者 not yet started(忘記的話，看下2.2節的內容)，故該事務插入的tuple對在當前為不可見；

Rule6，顯然，該tuple沒有被修改或者修改它的事務被abort了 = > 該tuple沒有被修改；插入該tuple的事務x在當前snapshot中是inactive(inactive說明事務x對於當前要執行的SQL命令來說要麽被提交了，要麽被abort了)，所以可見；

Rule7，如果tuple被當前事務UPDATE或者DELETE了，自然這個tuple對於我們來說是舊版本了，不可見；

Rule8，和Rule7對比，這個tuple是被別的事務x修改(UPDATE或者DELETE)了，而且事務x沒有被提交(postgreSQL不支持讀未提交)，所以修改後的元組對我們不可見，我們能看到的還是當前這個元組，所以當前tuple可見；

Rule9，雖然修改這個tuple的事務x已經提交了，但是事務x在當前snapshot中是active的，即對當前事務中的命令來說是 in progress 或者 not yet started(第二次用到這個假設了)，所以事務x的修改對當前命令不可見，所以我們看到了還是這個tuple；

Rule10，和上一條相反，修改這個tuple的事務x已經提交了，並且事務x在當前snapshot中是inactive(inactive說明事務x對於當前要執行的SQL命令來說要麽被提交了，要麽被abort了)的，所以對當前事務中的命令來說，這個事務x已經提交，所以這個tuple對當前事務中的命令而言，已經是被修改過了，即是舊版本的了，所以即為不可見。

3.PostgreSQL中的MVCC

又交代了一些基礎知識，下面正式進入MVCC。

3.1 元組可見性檢測

這一節我們來談論PostgreSQL中的"元組可見性"的檢測。

所謂"元組可見性"的檢測就是利用元組可見性規則來判斷一個tuple對當前事務中的執行語句是可見還是不可見。我們知道在PostgreSQL中是tuple是多版本，那麽對於一個事務中的命令來說，它需要找到對應事務中當前命令應該看到的那個版本的tuple進行處理。

通過"元組可見性"的檢測不僅僅可以幫助找到正確"版本"的tuple,同時還可以用來解決 ANSI SQL-92 標準中定義的異常：

臟讀；
不可重復讀；
幻讀

即，可以實現不同的事務隔離級別。

還是上例子吧：

技術分享圖片

簡化起見，txid=200的事務的隔離級別為READ COMMITTED，txid=201的事務的隔離級別我們分READ COMMITTED或者REPEATABLE READ兩種情況討論。

上圖中命令的執行順序如下：

T1 ：txid=200的事務開始

T2 ：txid=201的事務開始

T3 ：txid=200和txid=201的事務分別執行SELECT命令

T4 ：txid=200的事務執行UPDATE命令

T5 ：txid=200和txid=201的事務分別執行SELECT命令

T6 ：txid=200的事務commit

T7 ：txid=201的事務執行SELECT命令

下面我們就來看看PostgreSQL是如何執行"元組可見性"檢測的。

T3 ：
在T3時刻，當前表中只有Tuple_1，根據Rule6該tuple對所有事務可見；

T5 ：
在T5時刻的情況有所不同，我們對兩個事務分開討論。

對於txid = 200的事務，此刻，我們可知Tuple_1是不可見的(根據Rule7)，Tuple_2可見(根據Rule4);
因此，此時SELECT語句的返回結果為：

postgres=# -- txid 200
postgres=# SELECT * FROM tbl;
 name 
------
 Hyde
(1 row)

對於txid = 201的事務，此刻，我們可知Tuple_1是不可見的(根據Rule8)，Tuple_2同樣不可見(根據Rule2);
因此，此時SELECT語句的返回結果為：

postgres=# -- txid 201
postgres=# SELECT * FROM tbl;
  name 
--------
 Jekyll
(1 row)

我們可以看到，這裏txid = 201的事務不會讀取txid = 200的事務的未提交的更新，也就是回避了臟讀問題。在PostgreSQL所有的事務隔離級別中都不會造成臟讀。

T7 ：
在T7時刻，只有txid = 201的事務還在運行，txid = 200的事務已經提交。現在我們分兩種情況來討論txid = 201的事務的行為。

  • 1）txid = 201的事務的隔離級別為READ COMMITTED

    此時由於txid = 200的事務已經提交，因此，此時重新獲取的snapshot為 201:201: 。因此，我們可以知道Tuple_1是不可見的(根據Rule10)，Tuple_2是可見的(根據Rule6)，

因此，在READ COMMITTED級別下，SELECT語句的返回結果為：

postgres=# -- txid 201 (READ COMMITTED)
postgres=# SELECT * FROM tbl;
 name 
------
 Hyde
(1 row)

我們可以看到，該事務在隔離級別為READ COMMITTED時，前後兩次相同的SELECT獲取的結果不同，也就是不可重復讀。

  • 2）txid = 201的事務的隔離級別為REPEATABLE READ

    此時雖然txid = 200的事務已經提交，但是我們知道在REPEATABLE READ/SERIALIZABLE時，事務只在執行第一條命令時獲取一次snapshot，因此，此時snapshot仍保持不變為 200:200: 。因此，我們可以知道Tuple_1是不可見的(根據Rule9)，Tuple_2是可見的(根據Rule5)，

因此，在READ COMMITTED級別下，SELECT語句的返回結果為：

postgres=# -- txid 201 (READ COMMITTED)
postgres=# SELECT * FROM tbl;
  name 
--------
 Jekyll
(1 row)

我們可以看到，事務在隔離級別為REPEATABLE READ時，前後兩次相同的SELECT獲取的結果不變，即回避了不可重復讀。

到這裏，我們已經解決了解決了臟讀和不可重復讀的問題，那麽還有一個幻讀。然而幻讀在PostgreSQL的事務在隔離級別為REPEATABLE READ時存在麽？

我們知道，幻讀的定義是：一個事務重新執行一個返回符合一個搜索條件的行集合的查詢， 發現滿足條件的行集合因為另一個最近提交的事務而發生了改變。

顯然，在PostgreSQL中，由於快照隔離機制，我們繼續上面的分析就能發現：在REPEATABLE READ/SERIALIZABLE隔離級別時消除了幻讀(篇幅限制，我就不寫了)，即在從REPEATABLE READ開始就回避了幻讀的問題，這和其它數據庫上不太一樣，PostgreSQL中提供的隔離級別更加嚴格。

關於這個系列，還剩下"如何避免Lost Update"和"SSI(Serializable Snapshot Isolation)"這兩個問題沒討論，篇幅太長了，並不是寫論文，容樓主喝口茶，留在下篇再說吧~

淺析Postgres中的並發控制(Concurrency Control)與事務特性(上)（轉）

相關推薦

淺析Postgres中的並發控制(Concurrency Control)與事務特性(上)（轉）

工作原理 abort 保持 text 我認 理解 刪除 heap 普通 這篇博客將MVCC講的很透徹，以前自己懂了，很難給別人講出來，但是這篇文章給的例子就讓人很容易的復述出來，因此想記錄一下，轉載給更多的人 轉自：https://www.cnblogs.com/fl

淺析Postgres中的並發控制(Concurrency Control)與事務特性(上)

內容 bsp 讀取 point 無符號 clas 有一個 並發訪問 時間 轉載：https://www.cnblogs.com/flying-tiger/p/9567213.html#4121483#undefined PostgreSQL為開發者提供了一組豐富的工具來管理

淺析Postgres中的併發控制(Concurrency Control)與事務特性(下)

上文我們討論了PostgreSQL的MVCC相關的基礎知識以及實現機制。關於PostgreSQL中的MVCC，我們只講了元組可見性的問題，還剩下兩個問題沒講。一個是"Lost Update"問題，另一個是PostgreSQL中的序列化快照隔離機制(SSI，Serializable Snapshot Isola

電音中DJ/Producer/MC/EDM/Remix/Mix的名詞解釋（轉）

技術 賽事 兩把刷子 傳播 世界 曾經 cer ckey pro DJ DJ是Disc Jockey的縮寫，是電音圈子裏的一種熱門職業，一般大家在夜店或者酒吧看到的站在臺上甩著膀子擰著按鈕或者使勁兒搓碟的就是DJ啦。 DJ的主要工作一般就是在現場用打碟機和混音臺把許多適

【MM 發票】MM MIRO界面中的ITEM LIST的布局可自己定義（轉）

方便 jpg 下拉 定義 ges -1 bsp create http 轉載自 https://mp.weixin.qq.com/s/3WHQc885Muz9hPwfwP4ODA 進入如下界面： 輸入布局的名字，事務代碼，點‘Create’按鈕，進入如下界面： 可以將

TCP協議中的三次握手和四次揮手(圖解)（轉）

繼續 丟失 get 所有 如果 idt 請求報文 網絡 center 轉自：http://blog.csdn.net/whuslei/article/details/6667471 建立TCP需要三次握手才能建立，而斷開連接則需要四次握手。整個過程如下圖所示： 先來看看如

Android listview子控制元件的的點選事件（轉）

1.先看圖，是否是你想要的   2.佈局檔案<?xml version="1.0" encoding="utf-8"?><LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" androi

淺談HTTP中Get與Post的區別（轉）

     Http定義了與伺服器互動的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE。URL全稱是資源描述符，我們可以這樣認為：一個URL地址，它用於描述一個網路上的資源，而HTTP中的GET，POST，PUT，DELETE就對應著對這個

MySQL中變數的定義和變數的賦值使用（轉）

說明：現在市面上定義變數的教程和書籍基本都放在儲存過程上說明，但是儲存過程上變數只能作用於begin...end塊中，而普通的變數定義和使用都說的比較少，針對此類問題只能在官方文件中才能找到講解。 前言 MySQL儲存過程中，定義變數有兩種方式：  1、使用set或select直接賦值，變數名以@開頭 例如:

Netty中的Channel之資料沖刷與執行緒安全（writeAndFlush）

本文首發公眾號與個人部落格：Java貓說 & 貓叔的部落格 | MySelf，轉載請申明出處。 GitHub專案地址 InChat 一個輕量級、高效率的支援多端（應用與硬體Iot）的非同步網路應用通訊框架 前言 本文預設讀者已經瞭解了一定的Netty基礎

MySql中explain的時候出現using filesort，優化之（轉）

原文地址：http://blog.csdn.net/imzoer/article/details/8485680 在使用order by關鍵字的時候，如果待排序的內容不能由所使用的索引直接完成排序的話，那麼mysql有可能就要進行檔案排序。 【這個 filesort

android中EditText有游標不彈出軟鍵盤處理（轉）

if (android.os.Build.VERSION.SDK_INT <= 10) {et_input_batch_num_in.setInputType(InputType.TYPE_NULL); } else {getActivity().getWindow().setSoftInputMode

UNO R3從SD卡讀取圖片並顯示到2.2寸液晶屏上（220x176）

 折騰了一個週末，終於基本搞定。之前也玩過一陣，但沒能解決圖片大到一定程度後記憶體不足或者陣列超限的問題， 所以決定再試一下用SD卡。220x176的資料比較少，查了一圈壇內壇外中文外文的網站之後總算找到了一些思路。 大思路就是從SD卡中讀指定圖片檔案的每個畫素的RGB

js、html中的單引號、雙引號及其轉義使用（轉）

下面列出各種表達方法： <html> <body> <input value="外雙引號內雙引號-錯誤" type="button" onclick="alert("OK");" /><br /> <input value="外單引號內單引號-錯誤" ty

三分鐘看懂大資料風控中使用者行為資料的採集、分析及應用（ 轉 ）

據統計，目前銀行傳統的風控模型對市場上70%的客戶是有效的，但是對另外30%的使用者，其風控模型有效性將大打折扣。大資料風控作為傳統風控方式補充，主要利用行為資料來實施風險控制，使用者行為資料可以作為另外的30%客戶風控的有效補充。那麼，大資料風控運營中，會主要分析使用者的哪

MySQL中character set與collation的理解（轉）

var 數量 field nis ins character href The 方法 character set和collation的是什麽？ character set即字符集 我們常看到的UTF-8、GB2312、GB18030都是相互獨立的character se

Elasticsearch的樂觀並發控制和分片管理(更新中)

fresh 控制 新版本 ... 文檔 順序 搜索 per 並發 1. 樂觀並發控制 　　首先，需要明確Elasticsearch的三個特性： 分布式的：當文檔創建，刪除或更新的時候，新版本的文檔必須被復制到集群中的其他節點； 並發的：這些復制請求將被並行發送； 異步的：

Spring Security應用開發(11) 並發控制之實踐

nag line then 9.png page 總結 -c ole for 本文分別介紹了四種不同情況下，Spring Security的Session管理和並發控制的不同配置的配置方法，以及所產生的效果。 (1)首先編寫了session_error.jsp頁面，用於

Spring Security應用開發(10) 並發控制之基本介紹

authorize 失效 session report 表示 container 頁面 屬性 ren 同一個用戶使用不同的瀏覽器登錄，將會導致什麽結果呢？Spring Security提供了多種選項。 <!-- session管理 --> <

Shell腳本中的並發（轉）

itl back inux round tao top 修改 spa blog 轉自http://blog.csdn.net/wangtaoking1/article/details/9838571 主要記錄一下Shell腳本中的命令的並發和串行執行。 默認的情況下，Sh