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博客