本節是PostgreSQL 事務管理中的關於子事務部分的說明,翻譯自README檔案.

### 一、Subtransaction Handling
README
```
Subtransaction Handling
-----------------------
子事務處理

Subtransactions are implemented using a stack of TransactionState structures,
each of which has a pointer to its parent transaction's struct.  When a new
subtransaction is to be opened, PushTransaction is called, which creates a new
TransactionState, with its parent link pointing to the current transaction.
StartSubTransaction is in charge of initializing the new TransactionState to
sane values, and properly initializing other subsystems (AtSubStart routines).
子事務透過TransactionState結構體棧來實現,每一個TransactionState都有指向其父事務結構體的指標.
新的子事務即將開啟時,呼叫PushTransaction,該函式建立TransactionState結構體,parent指向當前事務.
StartSubTransaction負責完整初始化新的TransactionState結構體,並正確初始化其他子系統(AtSubStart例程實現).

When closing a subtransaction, either CommitSubTransaction has to be called
(if the subtransaction is committing), or AbortSubTransaction and
CleanupSubTransaction (if it's aborting).  In either case, PopTransaction is
called so the system returns to the parent transaction.
在關閉子事務時,成功則呼叫CommitSubTransaction,取消/失敗則呼叫AbortSubTransaction和CleanupSubTransaction.
無論哪種情況,都會呼叫PopTransaction以便返回到父事務.

One important point regarding subtransaction handling is that several may need
to be closed in response to a single user command.  That's because savepoints
have names, and we allow to commit or rollback a savepoint by name, which is
not necessarily the one that was last opened.  Also a COMMIT or ROLLBACK
command must be able to close out the entire stack.  We handle this by having
the utility command subroutine mark all the state stack entries as commit-
pending or abort-pending, and then when the main loop reaches
CommitTransactionCommand, the real work is done.  The main point of doing
things this way is that if we get an error while popping state stack entries,
the remaining stack entries still show what we need to do to finish up.
子事務處理一個很很重要的點是為了響應單個使用者命令需要關閉多個子事務.
這是因為對於命名savepoints,PG允許透過名稱提交或回滾至這些savepoint,而這些savepoint並不需要是最後才開啟的那個.
同時,COMMIT/ROLLBACK命令必須可以關閉整個棧.
透過工具命令子例程來標記整個狀態棧為commit-pending或者是abort-pending,
然後在主迴圈到達CommitTransactionCommand時,執行實際的commit/abort.
以這種方法做這些事情的主要關注點是如果在棧條目出棧時出現錯誤,剩餘的棧條目仍然可以展示我們需要做什麼才能完結.

In the case of ROLLBACK TO <savepoint>, we abort all the subtransactions up
through the one identified by the savepoint name, and then re-create that
subtransaction level with the same name.  So it's a completely new
subtransaction as far as the internals are concerned.
在ROLLBACK TO <savepoint>這種情況中,我們取消了從savepoint name到當前的所有子事務,
然後使用相同的名稱重建了該子事務.因此這是內部需要關注的完全的子事務.

Other subsystems are allowed to start "internal" subtransactions, which are
handled by BeginInternalSubTransaction.  This is to allow implementing
exception handling, e.g. in PL/pgSQL.  ReleaseCurrentSubTransaction and
RollbackAndReleaseCurrentSubTransaction allows the subsystem to close said
subtransactions.  The main difference between this and the savepoint/release
path is that we execute the complete state transition immediately in each
subroutine, rather than deferring some work until CommitTransactionCommand.
Another difference is that BeginInternalSubTransaction is allowed when no
explicit transaction block has been established, while DefineSavepoint is not.
其他子系統允許透過BeginInternalSubTransaction函式啟動"internal"子事務.
因此可以在諸如PL/pgSQL等程式語言中可以實現異常處理.
ReleaseCurrentSubTransaction和RollbackAndReleaseCurrentSubTransaction允許子系統關閉子事務.
這種方式跟savepoint/release的不同點是在每一個子例程中我們馬上執行了完整的狀態變換,
而不是等到執行CommitTransactionCommand才執行某些工作.
另外一個不同點是在沒有建立顯式事務塊的情況下允許呼叫BeginInternalSubTransaction,
而savepoint則需要明確的DefineSavepoint.

Transaction and Subtransaction Numbering
----------------------------------------
事務和子事務編號

Transactions and subtransactions are assigned permanent XIDs only when/if
they first do something that requires one --- typically, insert/update/delete
a tuple, though there are a few other places that need an XID assigned.
If a subtransaction requires an XID, we always first assign one to its
parent.  This maintains the invariant that child transactions have XIDs later
than their parents, which is assumed in a number of places.
事務和子事務在需要時才會分配持久的XIDs,典型的場景是insert/update/delete元組.
如果子事務需要XID,首先會給其父事務分配一個,這保證了子事務編號在父事務之後.

The subsidiary actions of obtaining a lock on the XID and entering it into
pg_subtrans and PG_PROC are done at the time it is assigned.
分配事務號還需要做的事情是在XID獲取鎖/寫入到pg_subtrans和PG_PROC中.

A transaction that has no XID still needs to be identified for various
purposes, notably holding locks.  For this purpose we assign a "virtual
transaction ID" or VXID to each top-level transaction.  VXIDs are formed from
two fields, the backendID and a backend-local counter; this arrangement allows
assignment of a new VXID at transaction start without any contention for
shared memory.  To ensure that a VXID isn't re-used too soon after backend
exit, we store the last local counter value into shared memory at backend
exit, and initialize it from the previous value for the same backendID slot
at backend start.  All these counters go back to zero at shared memory
re-initialization, but that's OK because VXIDs never appear anywhere on-disk.
沒有XID的事務仍然需要進行標識,特別是需要持有鎖的時候.
出於這個目的,我們分配了"虛擬事務號"(即VXID)給每一個頂層事務.
VXIDs由兩個域組成,後臺程式ID和後臺程式本地計數器;這樣的編號產生方法不需要共享記憶體爭用就可以進行新VXID的分配.
為了確保在後臺程式退出後VXID不會過快的被使用,我們把最後的本地計數器值儲存到共享記憶體中,
對於同一個後臺程式ID,分配先前儲存的計數器值給這個新的後臺程式.
在共享記憶體重新初始化後這些計數器會歸零,由於不會出現落盤,因此這樣的處理沒有任何問題.

Internally, a backend needs a way to identify subtransactions whether or not
they have XIDs; but this need only lasts as long as the parent top transaction
endures.  Therefore, we have SubTransactionId, which is somewhat like
CommandId in that it's generated from a counter that we reset at the start of
each top transaction.  The top-level transaction itself has SubTransactionId 1,
and subtransactions have IDs 2 and up.  (Zero is reserved for
InvalidSubTransactionId.)  Note that subtransactions do not have their
own VXIDs; they use the parent top transaction's VXID.
在內部實現上,不論子事務是否擁有XIDs,後臺程式需要標識子事務的方法;只要父頂級事務存在這種需求就好一直存在.
因此,產生了SubTransactionId,該欄位類似於CommandId,在每次頂層事務都會重置的計數器.
頂層事務本身的SubTransactionId設定為1,其他子事務的ID為2或更大(0保留用於InvalidSubTransactionId).
注意子事務沒有VXIDs;它們使用頂層事務的VXID.

```
TransactionState結構體
```

/*
 *	transaction states - transaction state from server perspective
 */
typedef enum TransState
{
	TRANS_DEFAULT,				/* idle */
	TRANS_START,				/* transaction starting */
	TRANS_INPROGRESS,			/* inside a valid transaction */
	TRANS_COMMIT,				/* commit in progress */
	TRANS_ABORT,				/* abort in progress */
	TRANS_PREPARE				/* prepare in progress */
} TransState;

/*
 *	transaction block states - transaction state of client queries
 *
 * Note: the subtransaction states are used only for non-topmost
 * transactions; the others appear only in the topmost transaction.
 */
typedef enum TBlockState
{
	/* not-in-transaction-block states */
	TBLOCK_DEFAULT,				/* idle */
	TBLOCK_STARTED,				/* running single-query transaction */

/* transaction block states */
	TBLOCK_BEGIN,				/* starting transaction block */
	TBLOCK_INPROGRESS,			/* live transaction */
	TBLOCK_IMPLICIT_INPROGRESS, /* live transaction after implicit BEGIN */
	TBLOCK_PARALLEL_INPROGRESS, /* live transaction inside parallel worker */
	TBLOCK_END,					/* COMMIT received */
	TBLOCK_ABORT,				/* failed xact, awaiting ROLLBACK */
	TBLOCK_ABORT_END,			/* failed xact, ROLLBACK received */
	TBLOCK_ABORT_PENDING,		/* live xact, ROLLBACK received */
	TBLOCK_PREPARE,				/* live xact, PREPARE received */

/* subtransaction states */
	TBLOCK_SUBBEGIN,			/* starting a subtransaction */
	TBLOCK_SUBINPROGRESS,		/* live subtransaction */
	TBLOCK_SUBRELEASE,			/* RELEASE received */
	TBLOCK_SUBCOMMIT,			/* COMMIT received while TBLOCK_SUBINPROGRESS */
	TBLOCK_SUBABORT,			/* failed subxact, awaiting ROLLBACK */
	TBLOCK_SUBABORT_END,		/* failed subxact, ROLLBACK received */
	TBLOCK_SUBABORT_PENDING,	/* live subxact, ROLLBACK received */
	TBLOCK_SUBRESTART,			/* live subxact, ROLLBACK TO received */
	TBLOCK_SUBABORT_RESTART		/* failed subxact, ROLLBACK TO received */
} TBlockState;

/*
 *	transaction state structure
 */
typedef struct TransactionStateData
{
	FullTransactionId fullTransactionId;	/* my FullTransactionId */
	SubTransactionId subTransactionId;	/* my subxact ID */
	char	   *name;			/* savepoint name, if any */
	int			savepointLevel; /* savepoint level */
	TransState	state;			/* low-level state */
	TBlockState blockState;		/* high-level state */
	int			nestingLevel;	/* transaction nesting depth */
	int			gucNestLevel;	/* GUC context nesting depth */
	MemoryContext curTransactionContext;	/* my xact-lifetime context */
	ResourceOwner curTransactionOwner;	/* my query resources */
	TransactionId *childXids;	/* subcommitted child XIDs, in XID order */
	int			nChildXids;		/* # of subcommitted child XIDs */
	int			maxChildXids;	/* allocated size of childXids[] */
	Oid			prevUser;		/* previous CurrentUserId setting */
	int			prevSecContext; /* previous SecurityRestrictionContext */
	bool		prevXactReadOnly;	/* entry-time xact r/o state */
	bool		startedInRecovery;	/* did we start in recovery? */
	bool		didLogXid;		/* has xid been included in WAL record? */
	int			parallelModeLevel;	/* Enter/ExitParallelMode counter */
	bool		chain;			/* start a new block after this one */
	struct TransactionStateData *parent;	/* back link to parent */
} TransactionStateData;

typedef TransactionStateData *TransactionState;

```

### 二、參考資料
[README](https://github.com/postgres/postgres/blob/master/src/backend/access/transam/README)</savepoint></savepoint>

PostgreSQL 原始碼解讀（225）- Transaction(子事務處理)

相關文章