执行函数:
准入条件:必须在事务块内,即顶级事务内TBLOCK_INPROGRESS 或子事务内 TBLOCK_SUBINPROGRESS。
static void
PushTransaction(void)
{
TransactionState p = CurrentTransactionState;
TransactionState s;
一定在顶层事务上下文TopTransactionContext上申请内存
s = (TransactionState)
MemoryContextAllocZero(TopTransactionContext,
sizeof(TransactionStateData));
currentSubTransactionId += 1;
...
...
s->fullTransactionId = InvalidFullTransactionId; /* until assigned */
s->subTransactionId = currentSubTransactionId;
s->parent = p;
s->nestingLevel = p->nestingLevel + 1;
s->gucNestLevel = NewGUCNestLevel();
继承父事务的savepointLevel。
s->savepointLevel = p->savepointLevel;
s->state = TRANS_DEFAULT;
s->blockState = TBLOCK_SUBBEGIN;
GetUserIdAndSecContext(&s->prevUser, &s->prevSecContext);
s->prevXactReadOnly = XactReadOnly;
s->parallelModeLevel = 0;
s->topXidLogged = false;
CurrentTransactionState = s;
}
PushTransaction效果:
CurrentTransactionState从顶层事务状态 → 子事务状态
顶层事务:
{ fullTransactionId = {value = 0},
subTransactionId = 1,
name = 0x0,
savepointLevel = 0,
state = TRANS_INPROGRESS,
blockState = TBLOCK_INPROGRESS,
nestingLevel = 1,
gucNestLevel = 1,
curTransactionContext = 0x1c891f0,
curTransactionOwner = 0x1ca9f88,
childXids = 0x0,
nChildXids = 0,
maxChildXids = 0,
prevUser = 10,
prevSecContext = 0,
prevXactReadOnly = false,
startedInRecovery = false,
didLogXid = false,
parallelModeLevel = 0,
chain = false,
topXidLogged = false,
parent = 0x0}
子事务:
{fullTransactionId = {value = 0},
subTransactionId = 2,
name = 0x0,
savepointLevel = 0,
state = TRANS_DEFAULT,
blockState = TBLOCK_SUBBEGIN,
nestingLevel = 2,
gucNestLevel = 2,
curTransactionContext = 0x0,
curTransactionOwner = 0x0,
childXids = 0x0,
nChildXids = 0,
maxChildXids = 0,
prevUser = 10,
prevSecContext = 0,
prevXactReadOnly = false,
startedInRecovery = false,
didLogXid = false,
parallelModeLevel = 0,
chain = false,
topXidLogged = false,
parent = 0xf17dc0 <TopTransactionStateData>}
static void
StartSubTransaction(void)
{
TransactionState s = CurrentTransactionState;
...
s->state = TRANS_START;
...
AtSubStart_Memory函数:
AtSubStart_Memory();
AtSubStart_ResourceOwner函数:
s->parent->curTransactionOwner
中拿到resowner,创建子resowner,并记录在并记录在CurrentTransactionState中。
AtSubStart_ResourceOwner();
AfterTriggerBeginSubXact();
s->state = TRANS_INPROGRESS;
执行callback,这些回调函数由RegisterSubXactCallback函数注册,在现有代码中发现几处:
_PG_init
会注册plpgsql_subxact_cb函数。 CallSubXactCallbacks(SUBXACT_EVENT_START_SUB, s->subTransactionId,
s->parent->subTransactionId);
ShowTransactionState("StartSubTransaction");
}
实例
drop table tbl1;
create table tbl1(i varchar(100));
begin;
savepoint sp1;
insert into tbl1 values('1');
savepoint sp2;
savepoint sp3;
insert into tbl1 values('2');
rollback to sp2;
rollback to导致事务状态变化
CommitTransactionCommand处理事务堆栈
plpgsql中的异常处理部分也是用子事务实现的,在begin end块中的语句都是运行在子事务下的,如果发生异常,所有的处理都会自动回滚,然后跳转到exception部分继续执行。也就是在plpgsql中只要有exception的语句,那么上面的begin中都会运行在子事务下。 pgpgsql的子事务使用PG提供的专用事务接口来实现:
使用位置:
exec_stmt_block
if (block->exceptions)
...
BeginInternalSubTransaction(NULL);
...
PG_TRY();
{
...
exec_stmts(estate, block->body);
...
ReleaseCurrentSubTransaction();
...
}
PG_CATCH();
{
RollbackAndReleaseCurrentSubTransaction();
...
rc = exec_stmts(estate, exception->action);
...
}
子事务系统
子事务使用TransactionState栈结构实现,具体实现中使用链表指向parent节点。子事务打开时,会用PushTransaction函数创建一个新的TransactionState出来,并调用StartSubTransaction函数初始化内存、资源管理器的状态。
子事务允许有名字,可以回滚到指定的检查点,所以用户的一条指令可能会处理多个子事务。另外像commit、rollback需要一次性把整个事务栈全部处理完。实现上,utility框架执行DDL会把目标子事务全部标记为commit-pending或abort-pending。当main loop到达CommitTransactionCommand时,做real work。为什么要这样做呢?因为当我们在处理某个子事务时(poping state stack entries)如果发生了错误,剩下的事务栈仍然需要继续处理完。在rollback to <savepoint>中,PG会撤销子事务直到发现名字为<savepoint>的子事务。注意<savepoint>也会被撤销掉,完了在重建出来。
另外子事务系统给plpgsql(或其他子系统)提供了:
上面的几个给子系统的专用接口和 SQL层常规接口savepoint/release
的区别是:
子事务ID
事务和子事务在真正需要事务ID时才会申请一个永久的XID,一般增删改和几个其他场景才会分配XID。
子事务申请XID时,总是会先给父事务分配XID,保证子事务XID晚于父事务XID。在获取XID时会同时拿到 XID锁(锁子系统)、录入PGPROC(PROC ARRAY子系统)、记录pg_subtrans(SLRU子系统)。
如果一个子事务需要一个 XID,我们总是首先将一个分配给它的父事务。这保持了子事务的 XID 晚于其父事务的不变性,这在许多地方都是假设的。获得 XID 上的锁并将其输入 pg_subtrans 和 PGPROC 的辅助操作在它被分配时完成。
没有 XID 的事务仍然需要出于各种目的进行标识,特别是持有锁。为此,我们为每个顶级交易分配一个“虚拟交易 ID”或 VXID。 VXID 由两个字段组成,backendID 和后端本地计数器;这种安排允许在事务开始时分配新的 VXID,而无需争用共享内存。为了确保 VXID 在后端退出后不会很快被重新使用,我们在后端退出时将最后一个本地计数器值存储到共享内存中,并在后端启动时从相同 backendID 插槽的先前值对其进行初始化。所有这些计数器在共享内存重新初始化时都归零,但这没关系,因为 VXID 永远不会出现在磁盘上的任何地方。
在内部,后端需要一种方法来识别子事务,无论它们是否具有 XID;但这需要只持续到父顶级事务持续的时间。因此,我们有 SubTransactionId,它有点像 CommandId,因为它是从我们在每个顶级事务开始时重置的计数器生成的。顶级事务本身有 SubTransactionId 1,子事务有 ID 2 及以上。 (零为 InvalidSubTransactionId 保留)请注意,子事务没有自己的 VXID;他们使用父顶级事务的 VXID。