本節是PostgreSQL 事務管理的簡要說明,翻譯自README檔案.

### 一、The Transaction System
README
```
src/backend/access/transam/README

The Transaction System
======================
事務系統

PostgreSQL's transaction system is a three-layer system.  The bottom layer
implements low-level transactions and subtransactions, on top of which rests
the mainloop's control code, which in turn implements user-visible
transactions and savepoints.
PostgreSQL的事務分為3層,底層實現了低層次的事務和子事務,在其頂上駐留主迴圈控制程式碼,
而主迴圈實現了使用者可見性事務和儲存點.

The middle layer of code is called by postgres.c before and after the
processing of each query, or after detecting an error:

StartTransactionCommand
		CommitTransactionCommand
		AbortCurrentTransaction

Meanwhile, the user can alter the system's state by issuing the SQL commands
BEGIN, COMMIT, ROLLBACK, SAVEPOINT, ROLLBACK TO or RELEASE.  The traffic cop
redirects these calls to the toplevel routines

BeginTransactionBlock
		EndTransactionBlock
		UserAbortTransactionBlock
		DefineSavepoint
		RollbackToSavepoint
		ReleaseSavepoint

respectively.  Depending on the current state of the system, these functions
call low level functions to activate the real transaction system:

StartTransaction
		CommitTransaction
		AbortTransaction
		CleanupTransaction
		StartSubTransaction
		CommitSubTransaction
		AbortSubTransaction
		CleanupSubTransaction

在處理查詢的前後或者檢測到錯誤時,postgres.c會呼叫中間層的程式碼:
		StartTransactionCommand
		CommitTransactionCommand
		AbortCurrentTransaction
在此期間,透過執行BEGIN/COMMIT/ROLLBACK/SAVEPOINT/ROLLBACK TO/RELEASE命令改變系統狀態.
排程程式會把這些呼叫重定向至相應的頂層例程上.
		BeginTransactionBlock
		EndTransactionBlock
		UserAbortTransactionBlock
		DefineSavepoint
		RollbackToSavepoint
		ReleaseSavepoint
依賴於當前的系統狀態,這些函式呼叫底層函式啟用真正的事務系統:
		StartTransaction
		CommitTransaction
		AbortTransaction
		CleanupTransaction
		StartSubTransaction
		CommitSubTransaction
		AbortSubTransaction
		CleanupSubTransaction

Additionally, within a transaction, CommandCounterIncrement is called to
increment the command counter, which allows future commands to "see" the
effects of previous commands within the same transaction.  Note that this is
done automatically by CommitTransactionCommand after each query inside a
transaction block, but some utility functions also do it internally to allow
some operations (usually in the system catalogs) to be seen by future
operations in the same utility command.  (For example, in DefineRelation it is
done after creating the heap so the pg_class row is visible, to be able to
lock it.)
另外,在事務內,呼叫CommandCounterIncrement增加命令計數,這可以讓未來的命令可以看到
在同一個事務中先前命令的影響.
注意該動作由CommitTransactionCommand在事務塊內部完成每個查詢後自動完成,
但某些工具函式同樣會內部實現此功能以允許某些操作(通常在系統目錄中)可被未來同樣的工具命令看到.
(比如,在DefineRelation,在建立堆後已完成,因此pg_class中的行已可見,並能執行鎖定)

For example, consider the following sequence of user commands:
舉個例子,考慮下面一組使用者命令:

1)		BEGIN
2)		SELECT * FROM foo
3)		INSERT INTO foo VALUES (...)
4)		COMMIT

In the main processing loop, this results in the following function call
sequence:
在主處理迴圈,會形成下面函式呼叫序列:

/  StartTransactionCommand; 	-- middle
    /       StartTransaction;	 	-- bottom
1) <    ProcessUtility;                 << BEGIN
    \       BeginTransactionBlock;	-- top
     \  CommitTransactionCommand;	-- middle

/   StartTransactionCommand;	-- middle
2) /    PortalRunSelect;                << SELECT ...
   \    CommitTransactionCommand;	-- middle
    \       CommandCounterIncrement;

/   StartTransactionCommand;	-- middle
3) /    ProcessQuery;                   << INSERT ...
   \    CommitTransactionCommand;	-- middle
    \       CommandCounterIncrement;

/  StartTransactionCommand;	-- middle
    /   ProcessUtility;                 << COMMIT
4) <        EndTransactionBlock;	-- top
    \   CommitTransactionCommand;	-- middle
     \      CommitTransaction;		-- bottom

The point of this example is to demonstrate the need for
StartTransactionCommand and CommitTransactionCommand to be state smart -- they
should call CommandCounterIncrement between the calls to BeginTransactionBlock
and EndTransactionBlock and outside these calls they need to do normal start,
commit or abort processing.
該例子想表達的意思是StartTransactionCommand和CommitTransactionCommand需要具備狀態智慧
-- 在BeginTransactionBlock/EndTransactionBlock之間需呼叫CommandCounterIncrement,
在這些呼叫之外,它們需要執行常規的start,commit或abort處理.

Furthermore, suppose the "SELECT * FROM foo" caused an abort condition. In
this case AbortCurrentTransaction is called, and the transaction is put in
aborted state.  In this state, any user input is ignored except for
transaction-termination statements, or ROLLBACK TO <savepoint> commands.
而且,假定"SELECT * FROM foo"出錯,導致需要abort,那麼會呼叫AbortCurrentTransaction(bottom),
事務狀態為aborted狀態.事務處於這個狀態,除了事務終止語句或者ROLLBACK TO <savepoint>命令外,所有使用者輸入都會被忽略.

Transaction aborts can occur in two ways:
事務取消的情況有兩種:

1) system dies from some internal cause  (syntax error, etc)
   內部原因,如語法錯誤等.
2) user types ROLLBACK
   使用者型別的ROLLBACK.

The reason we have to distinguish them is illustrated by the following two
situations:
區分事務取消的原因如下兩例所示:

case 1                                  case 2
        ------                                  ------
1) user types BEGIN                     1) user types BEGIN
2) user does something                  2) user does something
3) user does not like what              3) system aborts for some reason
   she sees and types ABORT                (syntax error, etc)

In case 1, we want to abort the transaction and return to the default state.
In case 2, there may be more commands coming our way which are part of the
same transaction block; we have to ignore these commands until we see a COMMIT
or ROLLBACK.
第一種情況,使用者希望取消事務並返回到預設狀態.
第二種情況,在同一個事務塊中,可能會有更多的命令進入,需要忽略這些命令直至COMMIT/ROLLBACK.

Internal aborts are handled by AbortCurrentTransaction, while user aborts are
handled by UserAbortTransactionBlock.  Both of them rely on AbortTransaction
to do all the real work.  The only difference is what state we enter after
AbortTransaction does its work:

* AbortCurrentTransaction leaves us in TBLOCK_ABORT,
* UserAbortTransactionBlock leaves us in TBLOCK_ABORT_END
內部的事務取消透過AbortCurrentTransaction(bottom)處理,而使用者取消透過UserAbortTransactionBlock(top)處理.
它們都需要依賴AbortTransaction(bottom)來處理實際的工作,不同的地方是在AbortTransaction後進入的狀態不同:
* AbortCurrentTransaction進入TBLOCK_ABORT
* UserAbortTransactionBlock進入TBLOCK_ABORT_END

Low-level transaction abort handling is divided in two phases:
* AbortTransaction executes as soon as we realize the transaction has
  failed.  It should release all shared resources (locks etc) so that we do
  not delay other backends unnecessarily.
* CleanupTransaction executes when we finally see a user COMMIT
  or ROLLBACK command; it cleans things up and gets us out of the transaction
  completely.  In particular, we mustn't destroy TopTransactionContext until
  this point.
底層事務取消處理分為兩個階段:
* 一旦感知事務已失敗,則馬上執行AbortTransaction,需要釋放所有的共享資源(比如鎖等)以便不影響其他後臺程式.
* 在使用者發出COMMIT/ROLLBACK時執行CleanupTransaction;清理現場並完整的跳出事務.
  特別地,在這個點上才需要銷燬TopTransactionContext

Also, note that when a transaction is committed, we don't close it right away.
Rather it's put in TBLOCK_END state, which means that when
CommitTransactionCommand is called after the query has finished processing,
the transaction has to be closed.  The distinction is subtle but important,
because it means that control will leave the xact.c code with the transaction
open, and the main loop will be able to keep processing inside the same
transaction.  So, in a sense, transaction commit is also handled in two
phases, the first at EndTransactionBlock and the second at
CommitTransactionCommand (which is where CommitTransaction is actually
called).
同時,注意如果事務已提交,必須要馬上關閉,而是進入TBLOCK_END狀態,
這意味著在查詢完成後執行CommitTransactionCommand,事務才會關閉.
這種區別很微妙，但很重要,因為控制已在事務開啟的情況下從xact.c程式碼中跳出,主迴圈仍在相同的主事務中.
因此,在某種意義上來說,事務提交存在兩個階段,首先EndTransactionBlock(top),其次CommitTransactionCommand(middle).
(CommitTransactionCommand是實際呼叫CommitTransaction的地方)

The rest of the code in xact.c are routines to support the creation and
finishing of transactions and subtransactions.  For example, AtStart_Memory
takes care of initializing the memory subsystem at main transaction start.
xact.c的剩餘程式碼是用於支援建立和結束事務和子事務的例程.
比如AtStart_Memory在主事務開啟時處理初始化記憶體子系統.

```

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 原始碼解讀（228）- Transaction(事務系統簡介)

相關文章