postgresql源码学习（五）—— 提交事务
结束事务分为两类：
- 提交：CommitTransaction
- 回滚（包含清理）：AbortTransaction
由于比较长，我们分开两篇记录。
一、 CommitTransaction
1. gdb测试
会话1，隐式事务会自动提交
会话2
跟之前一样，我们先只是过一遍这个函数流程，里面具体调用函数的步骤这里都会先跳过，避免深陷泥潭。Lets Go!
2. 具体代码与跟踪
调用栈如下
/*
* CommitTransaction
*
* 注意：如果想修改此函数逻辑，最好同时也修改 PrepareTransaction 函数
*/
static void
CommitTransaction(void)
{
TransactionState s = CurrentTransactionState; //事务栈
TransactionId latestXid;
bool is_parallel_worker;
is_parallel_worker = (s->blockState == TBLOCK_PARALLEL_INPROGRESS);
我看到这有点疑惑，之前的文章不是说隐式事务不会有INPROGRESS的状态吗？于是又回去翻了一下，噢，原来是隐式事务没有TBLOCK_INPROGRESS状态（事务块状态而不是事务状态）。这俩蛮容易弄混的，需要注意。postgresql源码学习（二）—— 事务块状态转换_Hehuyi_In的博客-CSDN博客
/* 如果是并行worker提交，强制进入并行模式. */
if (is_parallel_worker)
EnterParallelMode();
ShowTransactionState("CommitTransaction");
/*
* 检查当前事务状态
*/
if (s->state != TRANS_INPROGRESS)
elog(WARNING, "CommitTransaction while in %s state",
TransStateAsString(s->state));
Assert(s->parent == NULL);
/*
* Do pre-commit processing that involves calling user-defined code, such
* as triggers. SECURITY_RESTRICTED_OPERATION contexts must not queue an
* action that would run here, because that would bypass the sandbox.
* Since closing cursors could queue trigger actions, triggers could open
* cursors, etc, we have to keep looping until there's nothing left to do.
* 执行涉及调用用户定义代码(如触发器)的预提交处理。
* 因为关闭游标可能会执行触发器，触发器可能打开游标等等，所以我们必须一直循环，直到没有什么可做的。
*/
for (;;)
{
/*
* 触发所有after触发器
*/
AfterTriggerFireDeferred();
/*
* Close open portals (converting holdable ones into static portals).
* If there weren't any, we are done ... otherwise loop back to check
* if they queued deferred triggers. Lather, rinse, repeat.
* 关闭打开的portals（将holdable portals转换为static portals），portals好像是一种内存资源？
* 循环检查触发器队列直至全部关闭完
*/
if (!PreCommit_Portals(false))
break;
}
/*
* The remaining actions cannot call any user-defined code, so it's safe
* to start shutting down within-transaction services. But note that most
* of this stuff could still throw an error, which would switch us into
* the transaction-abort path.
* 剩余的操作不能调用用户自定义的代码，因此可以安全地开始关闭事务内的服务。
* 但是请注意，大多数这些动作仍然会抛出错误，这会导致流程切换到事务中止的路径上。
*/
CallXactCallbacks(is_parallel_worker ? XACT_EVENT_PARALLEL_PRE_COMMIT
: XACT_EVENT_PRE_COMMIT);
/* 如果有并行workers, 需要清理 */
if (IsInParallelMode())
AtEOXact_Parallel(true);
/* Shut down the deferred-trigger manager，关闭延迟触发器管理器 */
AfterTriggerEndXact(true);
/*
* Let ON COMMIT management do its thing (must happen after closing
* cursors, to avoid dangling-reference problems)
* 由ON COMMIT管理器执行（必须在关闭游标后执行，避免挂起引用问题）
*/
PreCommit_on_commit_actions();
/*
* Synchronize files that are created and not WAL-logged during this
* transaction. This must happen before AtEOXact_RelationMap(), so that we
* don't see committed-but-broken files after a crash.
* 同步该事务创建的没有WAL日志记录的文件。这步必须在AtEOXact_RelationMap()前执行，避免在crash后我们看不到已提交但是broken了的文件
*/
smgrDoPendingSyncs(true, is_parallel_worker);
/* close large objects before lower-level cleanup ，在低级别清理前关闭大对象 */
AtEOXact_LargeObject(true);
/*
* Insert notifications sent by NOTIFY commands into the queue. This
* should be late in the pre-commit sequence to minimize time spent
* holding the notify-insertion lock. However, this could result in
* creating a snapshot, so we must do it before serializable cleanup.
* 将NOTIFY命令发送的通知插入到队列中。这应该在预提交序列的末尾，以最小化持有notify-insertion锁的时间。然而这可能导致创建一个快照，因此必须在序列化清理前执行这步。
*/
PreCommit_Notify();
/*
* Mark serializable transaction as complete for predicate locking
* purposes. This should be done as late as we can put it and still allow
* errors to be raised for failure patterns found at commit. This is not
* appropriate in a parallel worker however, because we aren't committing
* the leader's transaction and its serializable state will live on.
*/
if (!is_parallel_worker)
PreCommit_CheckForSerializationFailure();
/* Prevent cancel/die interrupt while cleaning up，清理期间禁用中断，避免被打断 */
HOLD_INTERRUPTS();
/* Commit updates to the relation map --- do this as late as possible，提交更新到relation map -- 尽量晚地执行该动作 */
AtEOXact_RelationMap(true, is_parallel_worker);
注意这里有特别重要的两步：
- 设置事务状态为已提交 s->state = TRANS_COMMIT;
- 将事务日志写回磁盘 RecordTransactionCommit()，关于这步，以后还要继续深入学习
/*
* 设置事务状态
*/
s->state = TRANS_COMMIT;
s->parallelModeLevel = 0;
if (!is_parallel_worker)
{
/*
* We need to mark our XIDs as committed in pg_xact. This is where we
* durably commit.将已提交的xid保存在pg_xact中（事务日志写回磁盘），这是我们持久化提交的位置
*/
latestXid = RecordTransactionCommit();
}
else
{
/*
* We must not mark our XID committed; the parallel leader is
* responsible for that.并行worker则不需要标记，由并行leader处理
*/
latestXid = InvalidTransactionId;
/*
* Make sure the leader will know about any WAL we wrote before it
* commits.确保leader在提交之前知道worker写入的WAL
*/
ParallelWorkerReportLastRecEnd(XactLastRecEnd);
}
TRACE_POSTGRESQL_TRANSACTION_COMMIT(MyProc->lxid);
/*
* Let others know about no transaction in progress by me. Note that this
* must be done _before_ releasing locks we hold and _after_
* RecordTransactionCommit.
* 通知其他进程，本进程中已没有进行中的事务。
* 注意，这必须在释放持有的锁之前、RecordTransactionCommit之后执行。
*/
ProcArrayEndTransaction(MyProc, latestXid);
/*
* This is all post-commit cleanup. Note that if an error is raised here,
* it's too late to abort the transaction. This should be just
* noncritical resource releasing.
* 这些都是提交后清理。
* 请注意，如果这里才出现错误终止事务就太迟了，这应该是非关键的资源释放。
* The ordering of operations is not entirely random. The idea is:
* release resources visible to other backends (eg, files, buffer pins);
* then release locks; then release backend-local resources. We want to
* release locks at the point where any backend waiting for us will see
* our transaction as being fully cleaned up.
* 操作的顺序并不是完全随机的。
* 其思想是：先释放对其他后台进程可见的资源（如文件、buffer pins），然后释放锁，最后释放后端本地资源。
* 我们希望在所有等待本后台进程看到本事务被完全清理时才释放锁。
* Resources that can be associated with individual queries are handled by
* the ResourceOwner mechanism. The other calls here are for backend-wide
* state.
* 与单个查询关联的资源由ResourceOwner机制处理。
* 这里的其他调用是针对后台进程范围状态的。
*/
CallXactCallbacks(is_parallel_worker ? XACT_EVENT_PARALLEL_COMMIT
: XACT_EVENT_COMMIT);
ResourceOwnerRelease(TopTransactionResourceOwner,
RESOURCE_RELEASE_BEFORE_LOCKS,
true, true);
/* Check we've released all buffer pins，检查所有已释放的buffer pins */
AtEOXact_Buffers(true);
/* Clean up the relation cache，清理关系缓存 */
AtEOXact_RelationCache(true);
/*
* Make catalog changes visible to all backends. This has to happen after
* relcache references are dropped (see comments for
* AtEOXact_RelationCache), but before locks are released (if anyone is
* waiting for lock on a relation we've modified, we want them to know
* about the catalog change before they start using the relation).
* 使目录更改对所有后台进程可见。
* 这必须发生在relcache引用被删除之后(参见AtEOXact_RelationCache注释)，
* 但在锁被释放之前（如果有人在等待我们修改了的表的锁，我们希望他们在开始使用该表前知道目录的更改)。
*/
AtEOXact_Inval(true);
AtEOXact_MultiXact();
ResourceOwnerRelease(TopTransactionResourceOwner,
RESOURCE_RELEASE_LOCKS,
true, true);
ResourceOwnerRelease(TopTransactionResourceOwner,
RESOURCE_RELEASE_AFTER_LOCKS,
true, true);
/*
* Likewise, dropping of files deleted during the transaction is best done
* after releasing relcache and buffer pins. (This is not strictly
* necessary during commit, since such pins should have been released
* already, but this ordering is definitely critical during abort.) Since
* this may take many seconds, also delay until after releasing locks.
* Other backends will observe the attendant catalog changes and not
* attempt to access affected files.
* 同样，在事务期间删除的文件的清理最好在释放relcache和buffer pin之后进行。(这在提交过程中并不是必须的，因为这样的pins应该已经被释放了，但是该顺序在中止过程中绝对是至关重要的。)
* 因为这可能需要较长的时间，所以也要延迟到释放锁之后。
* 其他后台进程将监控相关的catalog更改，不尝试访问受影响的文件。
*/
smgrDoPendingDeletes(true);
AtCommit_Notify();
//一大波资源清理
AtEOXact_GUC(true, 1);
AtEOXact_SPI(true);
AtEOXact_Enum();
AtEOXact_on_commit_actions(true);
AtEOXact_Namespace(true, is_parallel_worker);
AtEOXact_SMgr();
AtEOXact_Files(true);
AtEOXact_ComboCid();
AtEOXact_HashTables(true);
AtEOXact_PgStat(true, is_parallel_worker);
AtEOXact_Snapshot(true, false);
AtEOXact_ApplyLauncher(true);
pgstat_report_xact_timestamp(0);
CurrentResourceOwner = NULL;
ResourceOwnerDelete(TopTransactionResourceOwner);
s->curTransactionOwner = NULL;
CurTransactionResourceOwner = NULL;
TopTransactionResourceOwner = NULL;
AtCommit_Memory();
// 重置事务栈变量
s->fullTransactionId = InvalidFullTransactionId;
s->subTransactionId = InvalidSubTransactionId;
s->nestingLevel = 0;
s->gucNestLevel = 0;
s->childXids = NULL;
s->nChildXids = 0;
s->maxChildXids = 0;
XactTopFullTransactionId = InvalidFullTransactionId;
nParallelCurrentXids = 0;
/*
* done with commit processing, set current transaction state back to default，完成事务提交后，将当前事务状态改回TRANS_DEFAULT
*/
s->state = TRANS_DEFAULT;
RESUME_INTERRUPTS(); //恢复中断
}
3. 主要流程图
二、 事务日志写回磁盘
上面流程图里最重要的是事务日志写回磁盘部分：RecordTransactionCommit()，保证已提交数据不会丢失。
if ((wrote_xlog && markXidCommitted &&
synchronous_commit > SYNCHRONOUS_COMMIT_OFF) ||
forceSyncCommit || nrels > 0) //判断是否要求同步提交，nrels > 0暂时没懂
{
XLogFlush(XactLastRecEnd); //如果是，则必须先写日志
/*
* Now we may update the CLOG, if we wrote a COMMIT record above。更新CLOG，更新事务状态
*/
if (markXidCommitted)
TransactionIdCommitTree(xid, nchildren, children);
}
else //如果是异步提交，不要求先写WAL，但崩溃时可能有数据丢失
{
/*设置异步提交最新的LSN */
XLogSetAsyncXactLSN(XactLastRecEnd);
/*
* 将最新的LSN保存到异步提交的事务组中，不要求先写WAL即可提交事务，同时将事务状态保存到CLOG中
*/
if (markXidCommitted)
TransactionIdAsyncCommitTree(xid, nchildren, children, XactLastRecEnd);
}RecordTransactionCommit函数内的主要调用流程如下，本篇我们暂时不详细分析了
参考：
《PostgreSQL技术内幕：事务处理深度探索》第1章
《PostgreSQL数据库内核分析》第7章
PostgreSQL 源码解读（122）- MVCC#7(提交事务-整体流程)_ITPUB博客
PostgreSQL 源码解读（123）- MVCC#8(提交事务-实际提交过程)_ITPUB博客