Postgresql source code (65) analysis of the working principle of the new snapshot system Globalvis

相关： 《Postgresql源码（18）PGPROC相关结构》《Postgresql源码（65）新快照体系Globalvis工作原理分析》《Postgresql快照优化Globalvis新体系分析（性能大幅增强）》《Improving Postgres Connection Scalability: Snapshots》

一些历史悠久的分析： 《Postgresql源码（28）获取快照GetSnapshotData流程分析和性能问题》

1 优化后的allProcs数组

先介绍下新版本PG删除了PGXACT结构后,事务ID是怎么存的：

• 之前的PGPROC和PGXACT结构是一一对应的,每个后端一个PGPROC、一个PGXACT,事务ID记录在PGXACT中,问题就像上一篇提的,PGXACT不是紧凑的,遍历起来无法高效利用cache.
• 新版本中,在PROC_HDR中原来的allPgXact不见了（指向PGXACT大数组）,取而代之的是xids紧凑数组,注意！这个数组和pgprocnos索引是对应的.
• 所以找一个PROC的xid,除了直接从PGPROC中读,还可以从PROC_HDR->xids读取,这个数组是紧凑的,遍历起来效率更高.

debug命令备忘（假设numProcs=3） p *procArray p allProcs[procArray->pgprocnos[0]] p allProcs[procArray->pgprocnos[1]] p allProcs[procArray->pgprocnos[2]] p ProcGlobal->xids[0] p ProcGlobal->xids[1] p ProcGlobal->xids[2]

2 GetSnapshotData第一部分——循环拿活跃事务

总结：

• 遍历ProcGlobal->xids数组,拿到所有的xid（优化一：紧凑数组）.
• 活跃的xid添加到快照的xip数组中.
• 顺便算一个xmin（函数栈变量）记录最小的活跃事务id.
• 读取PGXACT->xmin（优化二）
• xmax在进入循环前就算好了,一定是latestCompletedXid+1.
• 最后如果MyProc的xmin是无效的,更新一次PGPROC->xmin（还是要更新自己的xmin,这是必须的,无优化）
• 整个过程包在ProcArrayLock大锁中.

代码流程：

GetSnapshotData
  ...
  LWLockAcquire(ProcArrayLock, LW_SHARED)
  ...
  for (int pgxactoff = 0; pgxactoff < numProcs; pgxactoff++)
    TransactionId xid = UINT32_ACCESS_ONCE(other_xids[pgxactoff]);
    
    /* 如果xid>=xmax可以直接跳过,因为这个xid是在我拿快照后启动的,对我来说肯定不可见 */
    if (!NormalTransactionIdPrecedes(xid, xmax))
      continue;    
    
    /* 如果xid < xmin,xid也要包含在xmin中,xmin表示最小的活跃事务 */
    if (NormalTransactionIdPrecedes(xid, xmin))
      xmin = xid;
    
    /* 记录到快照中 */
    xip[count++] = xid;
  
  /* 更新一次xmin */
  if (!TransactionIdIsValid(MyProc->xmin))
    MyProc->xmin = TransactionXmin = xmin;

  LWLockRelease(ProcArrayLock);

复制

3 GetSnapshotData第二部分——维护GlobalVis

这部分要对比历史代码来看.

PG10

• 【0】前面把快照已经计算完了.下面“顺便”计算下全局最小可清理位点：RecentGlobalXmin.
• 【1】拿到最小事务ID.
• 【2】最小可清理位点传给RecentGlobalXmin,如果配了vacuum_defer_cleanup_age,把最小可清理位点,再往前推,清理时会保留更多的事务,给高延迟的备机使用.
• 【3】如果复制槽指定了某个位点,vacuum是不能清理的.

GetSnapshotData
    //【0】前面把快照已经计算完了.下面“顺便”计算下全局最小可清理位点：RecentGlobalXmin
    
    //【1】拿到最小事务ID
	if (TransactionIdPrecedes(xmin, globalxmin))
		globalxmin = xmin;
    
	//【2】最小可清理位点传给RecentGlobalXmin,如果配了vacuum_defer_cleanup_age
	// 把最小可清理位点,再往前推,清理时会保留更多的事务,给高延迟的备机使用
	RecentGlobalXmin = globalxmin - vacuum_defer_cleanup_age;
	if (!TransactionIdIsNormal(RecentGlobalXmin))
		RecentGlobalXmin = FirstNormalTransactionId;

	//【3】如果复制槽指定了某个位点,vacuum是不能清理的;
	if (TransactionIdIsValid(replication_slot_xmin) &&
		NormalTransactionIdPrecedes(replication_slot_xmin, RecentGlobalXmin))
		RecentGlobalXmin = replication_slot_xmin;
    ...
    ...

复制

PG14

测试场景：

事务一RC-----------4000440启动-------------------4000440结束------------------------------->
事务二RR----------------------4000450启动-----------------------------4000450结束---------->
事务三RC--------------------------------------------调试位置------------------------------->

复制

调试位置：

GetSnapshotData
    //【0】前面把快照已经计算完了.下面“顺便”计算下全局最小可清理位点,但是由于没有遍历PGPROC的xmin,只有自己遍历出来的xid,

	/* maintain state for GlobalVis* */
	{
		TransactionId def_vis_xid;
		TransactionId def_vis_xid_data;
		FullTransactionId def_vis_fxid;
		FullTransactionId def_vis_fxid_data;
		FullTransactionId oldestfxid;

        //【1】oldestfxid = 726
		oldestfxid = FullXidRelativeTo(latest_completed, oldestxid);
        
        //【2】def_vis_xid_data = 4000450
		def_vis_xid_data =
			TransactionIdRetreatedBy(xmin, vacuum_defer_cleanup_age);
        //【3】def_vis_xid_data = 4000450
		def_vis_xid_data =
			TransactionIdOlder(def_vis_xid_data, replication_slot_xmin);
        
        //【4】def_vis_xid = 4000450
		def_vis_xid = def_vis_xid_data;
		def_vis_xid = TransactionIdOlder(replication_slot_catalog_xmin, def_vis_xid);
		def_vis_fxid = FullXidRelativeTo(latest_completed, def_vis_xid);
		def_vis_fxid_data = FullXidRelativeTo(latest_completed, def_vis_xid_data);

        //【5】4000440 ----> 4000450
		GlobalVisSharedRels.definitely_needed =
			FullTransactionIdNewer(def_vis_fxid,
								   GlobalVisSharedRels.definitely_needed);
        ...
        //【6】4000440 ----> 4000440
		GlobalVisSharedRels.maybe_needed =
			FullTransactionIdNewer(GlobalVisSharedRels.maybe_needed,
								   oldestfxid);
        ...
	}

复制

总结：

• 【5】4000440 ----> 4000450：definitely_needed计算时实际上用的就是上面循环里面扫出来的最小的xid,在经过参数微调下（vacuumdelay和复制槽）,definitely_needed的含义比较好理解,运行中的事务都是>=这个值的.
• 【6】4000440 ----> 4000440：maybe_needed取值是取：newer(自己的值、最小的冻结事务ID）,这个值的含义是：小于这个值的事务应该都不活跃了.
• 不活跃 < maybe_needed < ... < definitely_needed <= 活跃,那maybe_needed和definitely_needed中间的值怎么知道有没有提交？

看下面函数：

bool
GlobalVisTestIsRemovableFullXid(GlobalVisState *state,
								FullTransactionId fxid)
{
    // 比maybe_needed小的肯定已经不活跃了,可以清理！
	if (FullTransactionIdPrecedes(fxid, state->maybe_needed))
		return true;

    // 比definitely_needed大于或等于,肯定活跃的,不能清理！
	if (FullTransactionIdFollowsOrEquals(fxid, state->definitely_needed))
		return false;

    // 中间的怎么办？调用GlobalVisUpdate
	if (GlobalVisTestShouldUpdate(state))
	{
	    // 调用ComputeXidHorizons计算每一个PROC的xmin,然后更新到GlobalVis变量中.
		GlobalVisUpdate();

		Assert(FullTransactionIdPrecedes(fxid, state->definitely_needed));

		return FullTransactionIdPrecedes(fxid, state->maybe_needed);
	}
	else
		return false;
}

复制

• （粗略判断）在判断具体一个XID能不能清理时,如果比definitely_needed大（或等）,或比maybe_needed小,可以直接返回.
• （需要时精确判断）在判断maybe_needed和definitely_needed中间的xid时,要走优化前的老逻辑,遍历每个PGPROC的xmin,拿到全局最小的xmin,然后调用GlobalVisUpdateApply更新全局变量GlobalVisSharedRels.maybe_needed、GlobalVisSharedRels.definitely_needed的值,提供给后面函数使用.

4 （重要）优化后不在循环内读取PGXACT->xmin会有什么影响？

1. 循环PGPROC时,看不到别的进程的xmin了,例如,一个RR事务A在拿快照的时候,最小事务ID：10还没提交,那么这个RR快照的xmin就是10.
2. 优化前,A事务后面新事务B构造快照时,能通过A的PGPROC看到xmin=10,并更新自己的xmin=10.
3. 优化后,A事务后面新事务B构造快照时,只能看到自己遍历时最小的xid,例如这时10已经提交了,B看到的是15,那么后构造的快照就会认为全局最小xmin=15,但是由于A的xmin是10,所以这时全局清理位点需要是10,不能是15.