Postgresql源码（123）事务提交时三段资源释放分析ResourceOwnerRelease

2024-02-20 15:12
文章标签 分析 源码 postgresql 资源 提交 123 事务 释放 三段 resourceownerrelease

本文主要是介绍Postgresql源码（123）事务提交时三段资源释放分析ResourceOwnerRelease，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

0 总结

  1. 三段释放原因：因为如果先释放锁，没有释放一些共享资源（比如pin住的buffer），别人拿到锁后发现我们仍然持有一些资源，就会有问题。所以三阶段释放主要是以锁为分界线，先释放锁保护的资源，在释放锁，在清理私有资源。这样可以保证别人拿到锁后，一定也能拿到对应的资源。
  2. 三段：先放pinned buffer、relation、dsm这些共享资源；再放锁；所有放其他会话看不到的私有资源。

1 资源随事务释放

三阶段释放是指ResourceOwnerRelease函数在使用时需要调用三次，按固定顺序调用每次删除特定的资源：

  1. RESOURCE_RELEASE_BEFORE_LOCKS
  2. RESOURCE_RELEASE_LOCKS
  3. RESOURCE_RELEASE_AFTER_LOCKS
typedef enum
{RESOURCE_RELEASE_BEFORE_LOCKS = 1,RESOURCE_RELEASE_LOCKS,RESOURCE_RELEASE_AFTER_LOCKS,
} ResourceReleasePhase;

例如事务提交时CommitTransaction：

static void
CommitTransaction(void).........ResourceOwnerRelease(TopTransactionResourceOwner,RESOURCE_RELEASE_BEFORE_LOCKS,true, true);/* Check we've released all 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).*/AtEOXact_Inval(true);AtEOXact_MultiXact();ResourceOwnerRelease(TopTransactionResourceOwner,RESOURCE_RELEASE_LOCKS,true, true);ResourceOwnerRelease(TopTransactionResourceOwner,RESOURCE_RELEASE_AFTER_LOCKS,true, true);......

其他几个事务控制函数资源释放时，也是按照相同的顺序分三阶段释放的：

函数名phaseisCommitisTopLevel
CommitTransactionRESOURCE_RELEASE_BEFORE_LOCKStruetrue
CommitTransactionRESOURCE_RELEASE_LOCKStruetrue
CommitTransactionRESOURCE_RELEASE_AFTER_LOCKStruetrue
PrepareTransactionRESOURCE_RELEASE_BEFORE_LOCKStruetrue
PrepareTransactionRESOURCE_RELEASE_LOCKStruetrue
PrepareTransactionRESOURCE_RELEASE_AFTER_LOCKStruetrue
AbortTransactionRESOURCE_RELEASE_BEFORE_LOCKSfalsetrue
AbortTransactionRESOURCE_RELEASE_LOCKSfalsetrue
AbortTransactionRESOURCE_RELEASE_AFTER_LOCKSfalsetrue
CommitSubTransactionRESOURCE_RELEASE_BEFORE_LOCKStruefalse
CommitSubTransactionRESOURCE_RELEASE_LOCKStruefalse
CommitSubTransactionRESOURCE_RELEASE_AFTER_LOCKStruefalse
AbortSubTransactionRESOURCE_RELEASE_BEFORE_LOCKSfalsefalse
AbortSubTransactionRESOURCE_RELEASE_LOCKSfalsefalse
AbortSubTransactionRESOURCE_RELEASE_AFTER_LOCKSfalsefalse

2 为什么要分三阶段释放？

结论

因为如果先释放锁，没有释放一些共享资源（比如pin住的buffer），别人拿到锁后发现我们仍然持有一些资源，就会有问题。所以三阶段释放主要是以锁为分界线，先释放锁保护的资源，在释放锁，在清理私有资源。这样可以保证别人拿到锁后，一定也能拿到对应的资源。

  1. RESOURCE_RELEASE_BEFORE_LOCKS（预锁定阶段）：需要释放对其他后端可见的资源（pinned buffers）。为了确保当我们释放另一个后端可能正在等待的锁时，它会看到我们已经完全退出了我们的事务。这是为了防止在释放锁之后，其他后端仍然看到我们持有的资源，从而可能导致数据不一致或其他问题。
  2. RESOURCE_RELEASE_LOCKS（锁定阶段）：释放持有的所有锁。这是为了让其他可能正在等待这些锁的后端能够继续执行。
  3. RESOURCE_RELEASE_AFTER_LOCKS（后锁定阶段）：后端内部的清理工作。释放那些只有后端自己知道的、不会影响其他后端的资源。

3 代码分析

下面这次提交后对resowner做了扩展性增强，代码逻辑没变但可读性有点差（PG17dev分支）

commit b8bff07daa85c837a2747b4d35cd5a27e73fb7b2
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Wed Nov 8 13:30:50 2023 +0200Make ResourceOwners more easily extensible.

围绕本篇主题，后面分析这次提交前代码（PG17前的逻辑）

static void
ResourceOwnerReleaseInternal(ResourceOwner owner,ResourceReleasePhase phase,bool isCommit,bool isTopLevel)
{ResourceOwner child;ResourceOwner save;ResourceReleaseCallbackItem *item;ResourceReleaseCallbackItem *next;Datum		foundres;

resowner维护树形结构，递归释放自己的child资源。

	for (child = owner->firstchild; child != NULL; child = child->nextchild)ResourceOwnerReleaseInternal(child, phase, isCommit, isTopLevel);...

3.1 第一阶段：RESOURCE_RELEASE_BEFORE_LOCKS

  1. 事务提交时不应该有正在进行中的io了，这里需要把标志位清理干净，避免影响后面事务使用这个buffer。
  2. 清理pinned的buffer
    • 提交时不应该有pinned的了，会告警，回滚时就无所谓了，因为错误不一定出在哪，不一定给机会清理。
  3. 关闭打开的relation
    • 提交时不应该有打开的了，会告警；回滚时同上。
  4. 关闭dsm段
  5. 关闭jit context
	if (phase == RESOURCE_RELEASE_BEFORE_LOCKS){while (ResourceArrayGetAny(&(owner->bufferioarr), &foundres)){Buffer		res = DatumGetBuffer(foundres);if (isCommit)elog(PANIC, "lost track of buffer IO on buffer %d", res);AbortBufferIO(res);}while (ResourceArrayGetAny(&(owner->bufferarr), &foundres)){Buffer		res = DatumGetBuffer(foundres);if (isCommit)PrintBufferLeakWarning(res);ReleaseBuffer(res);}while (ResourceArrayGetAny(&(owner->relrefarr), &foundres)){Relation	res = (Relation) DatumGetPointer(foundres);if (isCommit)PrintRelCacheLeakWarning(res);RelationClose(res);}while (ResourceArrayGetAny(&(owner->dsmarr), &foundres)){dsm_segment *res = (dsm_segment *) DatumGetPointer(foundres);if (isCommit)PrintDSMLeakWarning(res);dsm_detach(res);}while (ResourceArrayGetAny(&(owner->jitarr), &foundres)){JitContext *context = (JitContext *) DatumGetPointer(foundres);jit_release_context(context);}......}}

3.2 第二阶段：RESOURCE_RELEASE_LOCKS

  1. 如果是顶层事务，直接释放所有锁，具体：
    • 提交时要保留会话锁，释放事务锁。事务没了会话锁还需要继续生效，生命周期比事务长。
    • 回滚时要释放所有锁。
    • 会话锁：咨询锁。
    • 事务锁：行锁、表锁等。
  2. 如果是子事务，按提交回滚做出不同行为。
    • 提交：转移锁到parent resowner。
    • 回滚：释放锁。
	else if (phase == RESOURCE_RELEASE_LOCKS){if (isTopLevel){if (owner == TopTransactionResourceOwner){ProcReleaseLocks(isCommit);ReleasePredicateLocks(isCommit, false);}}else{LOCALLOCK **locks;int			nlocks;...if (isCommit)LockReassignCurrentOwner(locks, nlocks);elseLockReleaseCurrentOwner(locks, nlocks);}}

3.3 第三阶段：RESOURCE_RELEASE_AFTER_LOCKS

  1. 释放catcache系统表缓存。
  2. 释放cached plan。
  3. 释放tuple desc，注意tuple desc在构造好后，会用IncrTupleDescRefCount函数，在resowner中记录，按引用计数控制删除。引用计数的机制主要是为了处理TupleDesc在多个地方共享使用的情况。例如一个查询的多个部分可能都需要引用同一个TupleDesc。如果在一个部分结束时就直接删除TupleDesc，那么其他部分就无法继续使用这个TupleDesc了。
  4. 释放快照。
  5. 释放fd。
	else if (phase == RESOURCE_RELEASE_AFTER_LOCKS){while (ResourceArrayGetAny(&(owner->catrefarr), &foundres)){HeapTuple	res = (HeapTuple) DatumGetPointer(foundres);if (isCommit)PrintCatCacheLeakWarning(res);ReleaseCatCache(res);}while (ResourceArrayGetAny(&(owner->catlistrefarr), &foundres)){CatCList   *res = (CatCList *) DatumGetPointer(foundres);if (isCommit)PrintCatCacheListLeakWarning(res);ReleaseCatCacheList(res);}while (ResourceArrayGetAny(&(owner->planrefarr), &foundres)){CachedPlan *res = (CachedPlan *) DatumGetPointer(foundres);if (isCommit)PrintPlanCacheLeakWarning(res);ReleaseCachedPlan(res, owner);}while (ResourceArrayGetAny(&(owner->tupdescarr), &foundres)){TupleDesc	res = (TupleDesc) DatumGetPointer(foundres);if (isCommit)PrintTupleDescLeakWarning(res);DecrTupleDescRefCount(res);}while (ResourceArrayGetAny(&(owner->snapshotarr), &foundres)){Snapshot	res = (Snapshot) DatumGetPointer(foundres);if (isCommit)PrintSnapshotLeakWarning(res);UnregisterSnapshot(res);}/* Ditto for temporary files */while (ResourceArrayGetAny(&(owner->filearr), &foundres)){File		res = DatumGetFile(foundres);if (isCommit)PrintFileLeakWarning(res);FileClose(res);}}for (item = ResourceRelease_callbacks; item; item = next){next = item->next;item->callback(phase, isCommit, isTopLevel, item->arg);}CurrentResourceOwner = save;
}

这篇关于Postgresql源码（123）事务提交时三段资源释放分析ResourceOwnerRelease的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/728630。

相关文章

PostgreSQL 默认隔离级别的设置

PostgreSQL 默认隔离级别的设置

《PostgreSQL默认隔离级别的设置》PostgreSQL的默认事务隔离级别是读已提交,这是其事务处理系统的基础行为模式,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价... 目录一 默认隔离级别概述1.1 默认设置1.2 各版本一致性二 读已提交的特性2.1 行为特征2.2
阅读更多...
PostgreSQL中MVCC 机制的实现

PostgreSQL中MVCC 机制的实现

《PostgreSQL中MVCC机制的实现》本文主要介绍了PostgreSQL中MVCC机制的实现,通过多版本数据存储、快照隔离和事务ID管理实现高并发读写,具有一定的参考价值,感兴趣的可以了解一下... 目录一 MVCC 基本原理python1.1 MVCC 核心概念1.2 与传统锁机制对比二 Postg
阅读更多...
C++中RAII资源获取即初始化

C++中RAII资源获取即初始化

《C++中RAII资源获取即初始化》RAII通过构造/析构自动管理资源生命周期,确保安全释放,本文就来介绍一下C++中的RAII技术及其应用,具有一定的参考价值,感兴趣的可以了解一下... 目录一、核心原理与机制二、标准库中的RAII实现三、自定义RAII类设计原则四、常见应用场景1. 内存管理2. 文件操
阅读更多...
MyBatis Plus 中 update_time 字段自动填充失效的原因分析及解决方案(最新整理)

MyBatis Plus 中 update_time 字段自动填充失效的原因分析及解决方案(最新整理)

《MyBatisPlus中update_time字段自动填充失效的原因分析及解决方案(最新整理)》在使用MyBatisPlus时,通常我们会在数据库表中设置create_time和update... 目录前言一、问题现象二、原因分析三、总结：常见原因与解决方法对照表四、推荐写法前言在使用 MyBATis
阅读更多...
Python主动抛出异常的各种用法和场景分析

Python主动抛出异常的各种用法和场景分析

《Python主动抛出异常的各种用法和场景分析》在Python中,我们不仅可以捕获和处理异常,还可以主动抛出异常,也就是以类的方式自定义错误的类型和提示信息,这在编程中非常有用,下面我将详细解释主动抛... 目录一、为什么要主动抛出异常？二、基本语法：raise关键字基本示例三、raise的多种用法1. 抛
阅读更多...
github打不开的问题分析及解决

github打不开的问题分析及解决

《github打不开的问题分析及解决》：本文主要介绍github打不开的问题分析及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、找到github.com域名解析的ip地址二、找到github.global.ssl.fastly.net网址解析的ip地址三
阅读更多...
Mysql的主从同步/复制的原理分析

Mysql的主从同步/复制的原理分析

《Mysql的主从同步/复制的原理分析》：本文主要介绍Mysql的主从同步/复制的原理分析,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录为什么要主从同步？mysql主从同步架构有哪些？Mysql主从复制的原理/整体流程级联复制架构为什么好？Mysql主从复制注意
阅读更多...
java -jar命令运行 jar包时运行外部依赖jar包的场景分析

java -jar命令运行 jar包时运行外部依赖jar包的场景分析

《java-jar命令运行jar包时运行外部依赖jar包的场景分析》：本文主要介绍java-jar命令运行jar包时运行外部依赖jar包的场景分析,本文给大家介绍的非常详细,对大家的学习或工作... 目录Java -jar命令运行 jar包时如何运行外部依赖jar包场景：解决：方法一、启动参数添加： -Xb
阅读更多...
Apache 高级配置实战之从连接保持到日志分析的完整指南

Apache 高级配置实战之从连接保持到日志分析的完整指南

《Apache高级配置实战之从连接保持到日志分析的完整指南》本文带你从连接保持优化开始,一路走到访问控制和日志管理,最后用AWStats来分析网站数据,对Apache配置日志分析相关知识感兴趣的朋友... 目录Apache 高级配置实战：从连接保持到日志分析的完整指南前言 一、Apache 连接保持 - 性
阅读更多...
MySQL 事务的概念及ACID属性和使用详解

MySQL 事务的概念及ACID属性和使用详解

《MySQL事务的概念及ACID属性和使用详解》MySQL通过多线程实现存储工作,因此在并发访问场景中,事务确保了数据操作的一致性和可靠性,下面通过本文给大家介绍MySQL事务的概念及ACID属性和... 目录一、什么是事务二、事务的属性及使用2.1 事务的 ACID 属性2.2 为什么存在事务2.3 事务
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2