PostgreSQL 事务模型介绍

lishenghan

　　PostgreSQL有自己的事务实现模型。总体上分为三层：top layer, middle layer和bottom layer。
　　1. Top Layer
　　Top Layer主要由用户控制，对用户可见。这一层的事务，主要由用户来决定事务的发起与结束。事务生命周期由用户控制，是high-level的。

　　也就是通常所说的事务块，transaction block。当用户发起：BEGIN, COMMIT, ROLLBACK, SAVEPOINT, ROLLBACK TO or>　　PG的traffic cop会将这些call重新转发到Top Layer routine中，相对应的方法如下：
　　BeginTransactionBlock
　　EndTransactionBlock
　　UserAbortTransactionBlock
　　DefineSavepoint
　　RollbackToSavepoint
　　ReleaseSavepoint
　　2.Middle Layer
　　这一层基本上是语句级别的。对用户不可见，也就是说用户无法控制具体生命周期。这一层的处理是跟语句相对应的。由postgres.c处理，相对应的方法如下：
　　StartTransactionCommand
　　CommitTransactionCommand
　　AbortCurrentTransaction
　　3.Bottom Layer
　　这是最低层的事务原子性的实现，是row-level级别的。是真正意义上的事务实现，以及嵌套事务处理等。
　　相对应的方法如下：
　　StartTransaction
　　CommitTransaction
　　AbortTransaction
　　CleanupTransaction
　　StartSubTransaction
　　CommitSubTransaction
　　AbortSubTransaction
　　CleanupSubTransaction
　　从上面三层模型，可以看出PG事务管理粒度由粗到细。调用由中层向底层调用。另外如果有用户级别的事务控制，如出现“BEGIN”等，则被postgres.c转发到top layer中。
　　假设下面一个案例：
　　1)        BEGIN
　　2)        SELECT * FROM foo
　　3)        INSERT INTO foo VALUES (...)
　　4)        COMMIT
　　那么相应的调用方法调用循序如下:
　　/  StartTransactionCommand;
　　/       StartTransaction;
　　1)
　　\       BeginTransactionBlock;
　　\  CommitTransactionCommand;
　　/   StartTransactionCommand;
　　2) /        ProcessQuery;               
　　\        CommitTransactionCommand;
　　\       CommandCounterIncrement;
　　/   StartTransactionCommand;
　　3) /        ProcessQuery;               
　　\        CommitTransactionCommand;
　　\       CommandCounterIncrement;
　　/  StartTransactionCommand;
　　/   ProcessUtility;                 
　　4)
　　\   CommitTransactionCommand;
　　\      CommitTransaction;
　　在第一步中，用户定义的事务边界开始，也是此事务的生命周期起点。
　　首先，”BEGIN”也是作为一个命令语句的，因此本身这一步也是需要middle layer中的方法调用将其包围起来。

　　接着起动low-level事务，即由middle layer调用bottom layer的方法。StartTransaction时，会生成vxid(virtual transaction>　　判断当前事务是否是read-only或者目前是否处于recovery状态。事务隔离级别，事务是否异步commit等信息都在这里初始化。将transState状态设置为：TRANS_INPROCESS。
　　因为有“BEGIN”命令语句，所以是top layer的。因此又被转到BeginTransactionBlock逻辑中。开始transaction block 处理，并将事务状态设置为：TBLOCK_START。
　　起transaction block和起transaction的区别在于对事务状态的设置不一样。
　　start trasaction block是将事务状态设置为：TBLOCK_START，而一般的start transaction是将其设置为：TRANS_INPROCESS。
　　事务块与事务是有区别的，在状态上。事务块有以下几种状态，是可以嵌套的：

　　而一般事务，只有以下几种状态，没有嵌套：

　　另外，在源码定义上，用了不同的结构体来保存。TransState，保存low-level事务状态。
　　而TBlockState保存high-level事务状态。从这里也明显可以看出，PG在事务层级上做了区分的。

　　在第二步中，发起select查询。上面讲过，middle layer是跟命令语句对应的。因此针对select 查询，也是用middle layer中的方法调用将其包围。
　　另外增加CID，用于同一事务中的MVCC可见性判断。
　　在第三步中，发起insert操作。这一步大逻辑上基本上等同于第二步。只是在处理insert时，需要将当前的xid更新到tupler header中去。
　　通常涉及到insert,update,delete等操作都是跟heap紧密相关，涉及到heap的物理上tuple新增和删除。在这一层中，PG需要为每一个DML
　　操作assign一个事务ID，并将此事务ID更新到tuple header中的xmin或者xmax中。从而实现MVCC。另外这一层也会增加commandID，主要用来实现同一事务中的可见性判断。
　　在第四步中，用户发起commit，提交事务。事务生命周期结束。这一步逻辑等同于第一步。这里不仅需要结束top layer 的transaction block。也需要结束low-level中的事务，实现
　　事务原子性。另外还需要释放资源，释放buffer pin，释放锁等。
　　从上面的讲解中，我们可以比较清晰的看到，PG在事务实现的大致逻辑。完整实现ACID功能。
　　Atomity：原子性由low-level级别实现，从StartTransaction开始，结束于CommitTransaction。
　　Consistency：一致性由语句级别实现，即middle layer对应。另外在tuple header 中更新的xmin,xmax,cmin,cmax为事务可见性提供判断基础。
　　Isolation：在StartTransaction时，初始化事务隔离级别。为MVCC创建snapshot时，提供基础。
　　Duarability：通过CommitTransaction实现，提交事务日志等。为数据恢复和持久化提供基础。实现WAL（Write Ahead Log)功能。