PostgreSQL 14在MVCC上面有所增強，以保證在大批次客戶端連線場景下效能不會出現顯著下降（詳細可參見參考資料中的連結）。本節介紹了提交記錄“snapshot scalability: cache snapshots using a xact completion counter.”和“Fix race condition in snapshot caching when 2PC is used.”中的修改以及涉及的相關資料結構。

### 一、資料結構
**PROC_HDR**
```

/*
 * There is one ProcGlobal struct for the whole database cluster.
 * 全域性的ProcGlobal(PROC_HDR)結構體
 *
 * Adding/Removing an entry into the procarray requires holding *both*
 * ProcArrayLock and XidGenLock in exclusive mode (in that order). Both are
 * needed because the dense arrays (see below) are accessed from
 * GetNewTransactionId() and GetSnapshotData(), and we don't want to add
 * further contention by both using the same lock. Adding/Removing a procarray
 * entry is much less frequent.
 * 對proc陣列的插入和刪除,需要以獨佔的模式持有ProcArrayLock和XidGenLock,
 * 原因是GetNewTransactionId()和GetSnapshotData()函式需要訪問,並且我們不希望使用同樣的鎖來增加爭用.
 * 其實,插入和刪除proc陣列並不頻繁.
 *
 * Some fields in PGPROC are mirrored into more densely packed arrays (e.g.
 * xids), with one entry for each backend. These arrays only contain entries
 * for PGPROCs that have been added to the shared array with ProcArrayAdd()
 * (in contrast to PGPROC array which has unused PGPROCs interspersed).
 * PGPROC中的一些欄位映象到更稠密的陣列中(如xids),每一個後臺程式都有一項.
 * 這些陣列只包含使用ProcArrayAdd()加入到共享陣列的PGPROCs.
 *
 * The dense arrays are indexed by PGPROC->pgxactoff. Any concurrent
 * ProcArrayAdd() / ProcArrayRemove() can lead to pgxactoff of a procarray
 * member to change.  Therefore it is only safe to use PGPROC->pgxactoff to
 * access the dense array while holding either ProcArrayLock or XidGenLock.
 * 稠密陣列透過PGPROC->pgxactoff欄位進行索引,所有同步ProcArrayAdd和ProcArrayRemove操作
 * 會改變procarray中的pgxactoff成員變數.
 *
 * As long as a PGPROC is in the procarray, the mirrored values need to be
 * maintained in both places in a coherent manner.
 * 由於PGPROC在proc陣列中,映象值需要以一致的方式進行運維.
 *
 * The denser separate arrays are beneficial for three main reasons: First, to
 * allow for as tight loops accessing the data as possible. Second, to prevent
 * updates of frequently changing data (e.g. xmin) from invalidating
 * cachelines also containing less frequently changing data (e.g. xid,
 * statusFlags). Third to condense frequently accessed data into as few
 * cachelines as possible.
 * 基於以下3點原因,更稠密單獨的陣列會帶來不少好處.
 * 1.緊密的迴圈訪問資料成為可能;
 * 2.避免了對修改頻度不高的資料進行修改導致CPU快取無效的情況出現;
 * 3.使頻繁訪問的資料放在小量的CPU快取中成為可能.
 *
 * There are two main reasons to have the data mirrored between these dense
 * arrays and PGPROC. First, as explained above, a PGPROC's array entries can
 * only be accessed with either ProcArrayLock or XidGenLock held, whereas the
 * PGPROC entries do not require that (obviously there may still be locking
 * requirements around the individual field, separate from the concerns
 * here). That is particularly important for a backend to efficiently checks
 * it own values, which it often can safely do without locking.  Second, the
 * PGPROC fields allow to avoid unnecessary accesses and modification to the
 * dense arrays. A backend's own PGPROC is more likely to be in a local cache,
 * whereas the cachelines for the dense array will be modified by other
 * backends (often removing it from the cache for other cores/sockets). At
 * commit/abort time a check of the PGPROC value can avoid accessing/dirtying
 * the corresponding array value.
 * 讓這些稠密陣列和PGPROC之間生成資料映象,有兩個主要原因:
 * 1.如上所述,PGPROC陣列條目需要在持有ProcArrayLock和XidGenLock的前提下才能訪問,但實際上並不需要.
 *   在沒有鎖的情況下,後臺程式有效且安全的檢查自己的值是十分重要的.
 * 2.PGPROC中的欄位避免不必要的訪問和修改.後臺程式自己的PGPROC更應該在自己的本地快取中,
 *   而無需理會陣列會被其他程式修改.在事務提交或回滾時,檢查PGPROC值可以避免訪問或者弄髒相應的陣列值
 *
 * Basically it makes sense to access the PGPROC variable when checking a
 * single backend's data, especially when already looking at the PGPROC for
 * other reasons already.  It makes sense to look at the "dense" arrays if we
 * need to look at many / most entries, because we then benefit from the
 * reduced indirection and better cross-process cache-ability.
 * 檢查單個後臺程式資料時,訪問PGPROC值是比較敏感的,特別是在已經因為其他原因檢索過PGPROC的情況下
 *
 * When entering a PGPROC for 2PC transactions with ProcArrayAdd(), the data
 * in the dense arrays is initialized from the PGPROC while it already holds
 * ProcArrayLock.
 * 在2PC事務的情況下,透過ProcArrayAdd方法進入PGPROC時,
 *   陣列中的資料在持有ProcArrayLock鎖的情況下初始化陣列.
 */
typedef struct PROC_HDR
{
	/* Array of PGPROC structures (not including dummies for prepared txns) */
	//PGPROC結構體陣列
	PGPROC	   *allProcs;

/* Array mirroring PGPROC.xid for each PGPROC currently in the procarray */
	// 映象每一個PGPROC.xid
	TransactionId *xids;

/*
	 * Array mirroring PGPROC.subxidStatus for each PGPROC currently in the
	 * procarray.
	 */
	//映象PGPROC.subxidStatus
	XidCacheStatus *subxidStates;

/*
	 * Array mirroring PGPROC.statusFlags for each PGPROC currently in the
	 * procarray.
	 */
	//映象PGPROC.statusFlags
	uint8	   *statusFlags;

/* Length of allProcs array */
	//allProcs陣列的大小
	uint32		allProcCount;
	/* Head of list of free PGPROC structures */
	//空閒PGPROC結構體連結串列頭
	PGPROC	   *freeProcs;
	/* Head of list of autovacuum's free PGPROC structures */
	//autovacuum程式空閒PGPROC結構體連結串列頭
	PGPROC	   *autovacFreeProcs;
	/* Head of list of bgworker free PGPROC structures */
	//bgworker程式
	PGPROC	   *bgworkerFreeProcs;
	/* Head of list of walsender free PGPROC structures */
	//walsender
	PGPROC	   *walsenderFreeProcs;
	/* First pgproc waiting for group XID clear */
	//等待XID組清理的第一個pgproc
	pg_atomic_uint32 procArrayGroupFirst;
	/* First pgproc waiting for group transaction status update */
	//等待事務狀態組更新的首個pgproc
	pg_atomic_uint32 clogGroupFirst;
	/* WALWriter process's latch */
	//WALWriter程式latch
	Latch	   *walwriterLatch;
	/* Checkpointer process's latch */
	//檢查點程式latch
	Latch	   *checkpointerLatch;
	/* Current shared estimate of appropriate spins_per_delay value */
	//spins_per_delay
	int			spins_per_delay;
	/* The proc of the Startup process, since not in ProcArray */
	//Startup程式的proc結構體,不再Proc陣列中
	PGPROC	   *startupProc;
	int			startupProcPid;
	/* Buffer id of the buffer that Startup process waits for pin on, or -1 */
	//Startup程式等待pin的快取ID
	int			startupBufferPinWaitBufId;
} PROC_HDR;

extern PGDLLIMPORT PROC_HDR *ProcGlobal;

```

### 二、原始碼解讀
提交記錄和相關解析如下:
```
Previous commits made it faster/more scalable to compute snapshots. But not
building a snapshot is still faster. Now that GetSnapshotData() does not
maintain RecentGlobal* anymore, that is actually not too hard:
先前的提交使計算快照變得更快和更有擴充套件性。但構建快照並不見得更快。現在GetSnapshotData
不再維護RecentGlobal*相關的資料結構，實際上實現起來也不麻煩：

This commit introduces xactCompletionCount, which tracks the number of
top-level transactions with xids (i.e. which may have modified the database)
that completed in some form since the start of the server.
這次提交介紹了xactCompletionCount，該變數跟蹤具備xids的頂層事務（比如可能會更新資料庫）。

We can avoid rebuilding the snapshot's contents whenever the current
xactCompletionCount is the same as it was when the snapshot was
originally built.  Currently this check happens while holding
ProcArrayLock. While it's likely possible to perform the check without
acquiring ProcArrayLock, it seems better to do that separately /
later, some careful analysis is required. Even with the lock this is a
significant win on its own.
如果當前的xactCompletionCount與快照初始構建時一樣，那麼不再重新構建快照內容。
在持有ProcArrayLock鎖時才執行該檢查。由於沒有該鎖時並不會執行該檢查，
因此單獨或者延後執行檢檢視起來會更好，因為某些更仔細的分析是需要的。

On a smaller two socket machine this gains another ~1.03x, on a larger
machine the effect is roughly double (earlier patch version tested
though).  If we were able to safely avoid the lock there'd be another
significant gain on top of that.
在小型的兩路機器上，這樣的修改可以獲得1.03x的收益，在更大的機器上效果顯著達到了原來的2倍。
如果我們可以安全的避免鎖，那麼會有更顯著的收益。
```
原始碼解讀
```

diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index e9701ea7221549f02fb683766cbf024577066ca7..9d5d68f3fa7855daa4782cb162c7620ddb85bfc0 100644 (file)
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -524,6 +524,7 @@ SnapBuildBuildSnapshot(SnapBuild *builder)
    snapshot->curcid = FirstCommandId;
    snapshot->active_count = 0;
    snapshot->regd_count = 0;
    //初始化變數snapXactCompletionCount
+   snapshot->snapXactCompletionCount = 0;
 
    return snapshot;
 }
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index 96e4a87857602f03f9c856edefaa16af5e22e636..e687cde6f176fcf955df020ca29f3e1489dad0a0 100644 (file)
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -407,6 +407,7 @@ CreateSharedProcArray(void)
        procArray->lastOverflowedXid = InvalidTransactionId;
        procArray->replication_slot_xmin = InvalidTransactionId;
        procArray->replication_slot_catalog_xmin = InvalidTransactionId;
        //CreateSharedProcArray函式中,在初始化陣列時,設定xactCompletionCount為1
+       ShmemVariableCache->xactCompletionCount = 1;
    }
 
    allProcs = ProcGlobal->allProcs;
@@ -534,6 +535,9 @@ ProcArrayRemove(PGPROC *proc, TransactionId latestXid)
        /* Advance global latestCompletedXid while holding the lock */
        MaintainLatestCompletedXid(latestXid);
 
+       /* Same with xactCompletionCount  */
        //增加1(ProcArrayRemove函式)
+       ShmemVariableCache->xactCompletionCount++;
+
        ProcGlobal->xids[proc->pgxactoff] = 0;
        ProcGlobal->subxidStates[proc->pgxactoff].overflowed = false;
        ProcGlobal->subxidStates[proc->pgxactoff].count = 0;
@@ -667,6 +671,7 @@ ProcArrayEndTransactionInternal(PGPROC *proc, TransactionId latestXid)
 {
    size_t      pgxactoff = proc->pgxactoff;

//驗證是否持有鎖
+   Assert(LWLockHeldByMe(ProcArrayLock));
    Assert(TransactionIdIsValid(ProcGlobal->xids[pgxactoff]));
    Assert(ProcGlobal->xids[pgxactoff] == proc->xid);
 
@@ -698,6 +703,9 @@ ProcArrayEndTransactionInternal(PGPROC *proc, TransactionId latestXid)
 
    /* Also advance global latestCompletedXid while holding the lock */
    MaintainLatestCompletedXid(latestXid);
+
+   /* Same with xactCompletionCount  */
    //增加1(ProcArrayEndTransactionInternal函式)
+   ShmemVariableCache->xactCompletionCount++;
 }
 
 /*
@@ -1916,6 +1924,93 @@ GetMaxSnapshotSubxidCount(void)
    return TOTAL_MAX_CACHED_SUBXIDS;
 }
 
+/*
+ * Initialize old_snapshot_threshold specific parts of a newly build snapshot.
    初始化新構建快照中old_snapshot_threshold的指定域(啟用了快照過舊特性)
+ */
+static void
+GetSnapshotDataInitOldSnapshot(Snapshot snapshot)
+{
+   if (!OldSnapshotThresholdActive())
+   {
+       /*
+        * If not using "snapshot too old" feature, fill related fields with
+        * dummy values that don't require any locking.
+        */
        //沒有啟用快照過舊特性,填充相關域值
+       snapshot->lsn = InvalidXLogRecPtr;
+       snapshot->whenTaken = 0;
+   }
+   else
+   {
+       /*
+        * Capture the current time and WAL stream location in case this
+        * snapshot becomes old enough to need to fall back on the special
+        * "old snapshot" logic.
           啟用了快照過舊特性,收集當前時間和WAL位置並填充到相應的位置中
+        */
+       snapshot->lsn = GetXLogInsertRecPtr();
+       snapshot->whenTaken = GetSnapshotCurrentTimestamp();
+       MaintainOldSnapshotTimeMapping(snapshot->whenTaken, snapshot->xmin);
+   }
+}
+
+/*
+ * Helper function for GetSnapshotData() that checks if the bulk of the
+ * visibility information in the snapshot is still valid. If so, it updates
+ * the fields that need to change and returns true. Otherwise it returns
+ * false.
    GetSnapshotData的助手函式,用於檢查快照中可見性資訊是否仍然有效.
    如有效,則更新需要更新的域並返回true,否則返回false.
+ *
+ * This very likely can be evolved to not need ProcArrayLock held (at very
+ * least in the case we already hold a snapshot), but that's for another day.
+ */
+static bool
+GetSnapshotDataReuse(Snapshot snapshot)
+{
+   uint64 curXactCompletionCount;
+
+   Assert(LWLockHeldByMe(ProcArrayLock));
+
+   if (unlikely(snapshot->snapXactCompletionCount == 0))
+       return false;
+
    //從共享記憶體中獲取事務計數
+   curXactCompletionCount = ShmemVariableCache->xactCompletionCount;
    //不相等,則返回false
+   if (curXactCompletionCount != snapshot->snapXactCompletionCount)
+       return false;
+
+   /*
+    * If the current xactCompletionCount is still the same as it was at the
+    * time the snapshot was built, we can be sure that rebuilding the
+    * contents of the snapshot the hard way would result in the same snapshot
+    * contents:
        如果當前的xactCompletionCount與快照建立時的計數一樣,那我們可以斷定重新構建快照內容
        其實跟原來是一樣的.
+    *
+    * As explained in transam/README, the set of xids considered running by
+    * GetSnapshotData() cannot change while ProcArrayLock is held. Snapshot
+    * contents only depend on transactions with xids and xactCompletionCount
+    * is incremented whenever a transaction with an xid finishes (while
+    * holding ProcArrayLock) exclusively). Thus the xactCompletionCount check
+    * ensures we would detect if the snapshot would have changed.
        就如在transam/README中已解釋過的,
        GetSnapshotData認為正在執行的xids集合在持有ProcArrayLock鎖時是不能改變的.
        快照內容僅僅依賴於已分配xids的事務,而在事務結束時xactCompletionCount會加一.
        因此xactCompletionCount的檢查確保可以偵測到快照的變化.
+    *
+    * As the snapshot contents are the same as it was before, it is is safe
+    * to re-enter the snapshot's xmin into the PGPROC array. None of the rows
+    * visible under the snapshot could already have been removed (that'd
+    * require the set of running transactions to change) and it fulfills the
+    * requirement that concurrent GetSnapshotData() calls yield the same
+    * xmin.
        由於快照內容與先前的一樣,重新把快照的xmin放到PGPROC陣列中是安全的.        
+    */
+   if (!TransactionIdIsValid(MyProc->xmin))
+       MyProc->xmin = TransactionXmin = snapshot->xmin;//更新xmin
+
+   RecentXmin = snapshot->xmin;
+   Assert(TransactionIdPrecedesOrEquals(TransactionXmin, RecentXmin));
+
    //更新snapshot的相關資訊
+   snapshot->curcid = GetCurrentCommandId(false);
+   snapshot->active_count = 0;
+   snapshot->regd_count = 0;
+   snapshot->copied = false;
+
    //初始化快照過舊的資訊
+   GetSnapshotDataInitOldSnapshot(snapshot);
+
    //返回true
+   return true;
+}
+
 /*
  * GetSnapshotData -- returns information about running transactions.
  *
@@ -1963,6 +2058,7 @@ GetSnapshotData(Snapshot snapshot)
    TransactionId oldestxid;
    int         mypgxactoff;
    TransactionId myxid;
+   uint64      curXactCompletionCount;
 
    TransactionId replication_slot_xmin = InvalidTransactionId;
    TransactionId replication_slot_catalog_xmin = InvalidTransactionId;
@@ -2007,12 +2103,19 @@ GetSnapshotData(Snapshot snapshot)
     */
    LWLockAcquire(ProcArrayLock, LW_SHARED);
    
    //快照是否可重用?如可以,則直接返回
+   if (GetSnapshotDataReuse(snapshot))
+   {
+       LWLockRelease(ProcArrayLock);
+       return snapshot;
+   }
+
    latest_completed = ShmemVariableCache->latestCompletedXid;
    mypgxactoff = MyProc->pgxactoff;
    myxid = other_xids[mypgxactoff];
    Assert(myxid == MyProc->xid);
 
    oldestxid = ShmemVariableCache->oldestXid;
    //更新事務計數
+   curXactCompletionCount = ShmemVariableCache->xactCompletionCount;
 
    /* xmax is always latestCompletedXid + 1 */
    xmax = XidFromFullTransactionId(latest_completed);
@@ -2266,6 +2369,7 @@ GetSnapshotData(Snapshot snapshot)
    snapshot->xcnt = count;
    snapshot->subxcnt = subcount;
    snapshot->suboverflowed = suboverflowed;
    //更新快照事務計數
+   snapshot->snapXactCompletionCount = curXactCompletionCount;
 
    snapshot->curcid = GetCurrentCommandId(false);
 
@@ -2277,26 +2381,7 @@ GetSnapshotData(Snapshot snapshot)
    snapshot->regd_count = 0;
    snapshot->copied = false;

//下面的程式碼已移入GetSnapshotDataReuse函式
-   if (old_snapshot_threshold < 0)
-   {
-       /*
-        * If not using "snapshot too old" feature, fill related fields with
-        * dummy values that don't require any locking.
-        */
-       snapshot->lsn = InvalidXLogRecPtr;
-       snapshot->whenTaken = 0;
-   }
-   else
-   {
-       /*
-        * Capture the current time and WAL stream location in case this
-        * snapshot becomes old enough to need to fall back on the special
-        * "old snapshot" logic.
-        */
-       snapshot->lsn = GetXLogInsertRecPtr();
-       snapshot->whenTaken = GetSnapshotCurrentTimestamp();
-       MaintainOldSnapshotTimeMapping(snapshot->whenTaken, xmin);
-   }
    //改為呼叫函式
+   GetSnapshotDataInitOldSnapshot(snapshot);
 
    return snapshot;
 }
diff --git a/src/backend/utils/time/snapmgr.c b/src/backend/utils/time/snapmgr.c
index c208538e2e5ca32d6e9ce1d8bb61fe56d54f704e..22cf3ebaf4728d0295fbed11dec3fe00e7e81d7a 100644 (file)
--- a/src/backend/utils/time/snapmgr.c
+++ b/src/backend/utils/time/snapmgr.c
@@ -597,6 +597,8 @@ SetTransactionSnapshot(Snapshot sourcesnap, VirtualTransactionId *sourcevxid,
    CurrentSnapshot->takenDuringRecovery = sourcesnap->takenDuringRecovery;
    /* NB: curcid should NOT be copied, it's a local matter */
    
    //設定快照計數
+   CurrentSnapshot->snapXactCompletionCount = 0;
+
    /*
     * Now we have to fix what GetSnapshotData did with MyProc->xmin and
     * TransactionXmin.  There is a race condition: to make sure we are not
@@ -672,6 +674,7 @@ CopySnapshot(Snapshot snapshot)
    newsnap->regd_count = 0;
    newsnap->active_count = 0;
    newsnap->copied = true;
    //設定快照計數
+   newsnap->snapXactCompletionCount = 0;
 
    /* setup XID array */
    if (snapshot->xcnt > 0)
@@ -2209,6 +2212,7 @@ RestoreSnapshot(char *start_address)
    snapshot->curcid = serialized_snapshot.curcid;
    snapshot->whenTaken = serialized_snapshot.whenTaken;
    snapshot->lsn = serialized_snapshot.lsn;
    //設定快照計數
+   snapshot->snapXactCompletionCount = 0;
 
    /* Copy XIDs, if present. */
    if (serialized_snapshot.xcnt > 0)
diff --git a/src/include/access/transam.h b/src/include/access/transam.h
index b32044153b09d9fac6264c4812427294d624360f..2f1f144db4d062a374104bc62d382d0d5c7c4de7 100644 (file)
--- a/src/include/access/transam.h
+++ b/src/include/access/transam.h
@@ -231,6 +231,15 @@ typedef struct VariableCacheData
    FullTransactionId latestCompletedXid;   /* newest full XID that has
                                             * committed or aborted */
 
+   /*
+    * Number of top-level transactions with xids (i.e. which may have
+    * modified the database) that completed in some form since the start of
+    * the server. This currently is solely used to check whether
+    * GetSnapshotData() needs to recompute the contents of the snapshot, or
+    * not. There are likely other users of this.  Always above 1.
+    */
    //VariableCacheData資料結構,新增xactCompletionCount
+   uint64 xactCompletionCount;
+
    /*
     * These fields are protected by XactTruncationLock
     */
diff --git a/src/include/utils/snapshot.h b/src/include/utils/snapshot.h
index 35b1f05bea6593c6c5df28b3fb3bbf51b132c6a0..dea072e5edf5e881e172cebb81a5c8c29398e65c 100644 (file)
--- a/src/include/utils/snapshot.h
+++ b/src/include/utils/snapshot.h
@@ -207,6 +207,13 @@ typedef struct SnapshotData
 
    TimestampTz whenTaken;      /* timestamp when snapshot was taken */
    XLogRecPtr  lsn;            /* position in the WAL stream when taken */
+
+   /*
+    * The transaction completion count at the time GetSnapshotData() built
+    * this snapshot. Allows to avoid re-computing static snapshots when no
+    * transactions completed since the last GetSnapshotData().
+    */
    //SnapshotData資料結構,新增xactCompletionCount
+   uint64      snapXactCompletionCount;
 } SnapshotData;
 
 #endif                         /* SNAPSHOT_H */

diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index e687cde6f176fcf955df020ca29f3e1489dad0a0..51f8099cad2ca43d7be1c5b5f66426d282fdbcb1 100644 (file)
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -860,6 +860,15 @@ ProcArrayClearTransaction(PGPROC *proc)
    Assert(!(proc->vacuumFlags & PROC_VACUUM_STATE_MASK));
    Assert(!proc->delayChkpt);
 
+   /*
+    * Need to increment completion count even though transaction hasn't
+    * really committed yet. The reason for that is that GetSnapshotData()
+    * omits the xid of the current transaction, thus without the increment we
+    * otherwise could end up reusing the snapshot later. Which would be bad,
+    * because it might not count the prepared transaction as running.
+    */
    //增加xactCompletionCount計數
+   ShmemVariableCache->xactCompletionCount++;
+
    /* Clear the subtransaction-XID cache too */
    Assert(ProcGlobal->subxidStates[pgxactoff].count == proc->subxidStatus.count &&
           ProcGlobal->subxidStates[pgxactoff].overflowed == proc->subxidStatus.overflowed);
```

### 三、跟蹤分析
N/A

### 四、參考資料
1.[Improving connection scalability: GetSnapshotData()](https://www.postgresql.org/message-id/20200301083601.ews6hz5dduc3w2se%40alap3.anarazel.de)
2.[snapshot scalability: cache snapshots using a xact completion counter.](https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=623a9ba79bbdd11c5eccb30b8bd5c446130e521c)
3.[Fix race condition in snapshot caching when 2PC is used.](https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=07f32fcd23ac81898ed47f88beb569c631a2f223)

PostgreSQL 原始碼解讀（262）- PG 14（Improving connection scalability）#14

相關文章