PostgreSQL 事务模型介绍

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
简介:

    PostgreSQL有自己的事务实现模型。总体上分为三层:top layer, middle layer和bottom layer。

1. Top Layer

Top Layer主要由用户控制,对用户可见。这一层的事务,主要由用户来决定事务的发起与结束。事务生命周期由用户控制,是high-level的。

也就是通常所说的事务块,transaction block。当用户发起:BEGIN, COMMIT, ROLLBACK, SAVEPOINT, ROLLBACK TO or RELEASE等命令时,

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) <        ProcessUtility;             << BEGIN
    \       BeginTransactionBlock;
     \  CommitTransactionCommand;

    /   StartTransactionCommand;
2) /        ProcessQuery;               << SELECT ...
   \        CommitTransactionCommand;
    \       CommandCounterIncrement;

    /   StartTransactionCommand;
3) /        ProcessQuery;               << INSERT ...
   \        CommitTransactionCommand;
    \       CommandCounterIncrement;

     /  StartTransactionCommand;
    /   ProcessUtility;                 << COMMIT
4) <            EndTransactionBlock;
    \   CommitTransactionCommand;
     \      CommitTransaction;

在第一步中,用户定义的事务边界开始,也是此事务的生命周期起点。

首先,”BEGIN”也是作为一个命令语句的,因此本身这一步也是需要middle layer中的方法调用将其包围起来。

接着起动low-level事务,即由middle layer调用bottom layer的方法。StartTransaction时,会生成vxid(virtual transaction id,即backend id与local transaction id)。

判断当前事务是否是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。

事务块与事务是有区别的,在状态上。事务块有以下几种状态,是可以嵌套的:

image

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

image

另外,在源码定义上,用了不同的结构体来保存。TransState,保存low-level事务状态。

而TBlockState保存high-level事务状态。从这里也明显可以看出,PG在事务层级上做了区分的。

image

在第二步中,发起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)功能。

本文转自ICT时空 dbasdk博客,原文链接:PostgreSQL 事务模型介绍 ,如需转载请自行联系原博主。

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
6月前
|
人工智能 关系型数据库 分布式数据库
沉浸式学习PostgreSQL|PolarDB 9: AI大模型+向量数据库, 提升AI通用机器人在专业领域的精准度, 完美诠释柏拉图提出的“知识是回忆而不是知觉”
越来越多的企业和个人希望能够利用LLM和生成式人工智能来构建专注于其特定领域的具备AI能力的产品。目前,大语言模型在处理通用问题方面表现较好,但由于训练语料和大模型的生成限制,对于垂直专业领域,则会存在知识深度和时效性不足的问题。在信息时代,由于企业的知识库更新频率越来越高,并且企业所拥有的垂直领域知识库(例如文档、图像、音视频等)往往是未公开或不可公开的。因此,对于企业而言,如果想在大语言模型的基础上构建属于特定垂直领域的AI产品,就需要不断将自身的知识库输入到大语言模型中进行训练。
793 0
|
6月前
|
人工智能 关系型数据库 分布式数据库
沉浸式学习PostgreSQL|PolarDB 17: 向量数据库, 通义大模型AI的外脑
chatbot是大模型应用之一, 在与chatbot沟通时会遇到token上限问题, 例如通义目前是8K, chatgpt是4K. 也就是问题上下文(包含多轮对话的内容)最多8k或4k, 超出就无法处理了. 解释一下token: 对于通义模型来说, 中文字符串的token就是字数(含符号). 英文则可能是词、片段等. 我们的核心目的是通过有限的上下文来拿到结果. 这就需要你的prompt(上下文)足够精确, 防止无效垃圾对话浪费token限额. 上下文的组成: 1、每一轮对话的提问内容和大模型的回答内容 2、外脑中的FAQ 这个实验体验的就是怎么建设AI的外脑? 向量数据库的核心价值:AI外脑
1340 4
|
6月前
|
人工智能 关系型数据库 分布式数据库
沉浸式学习PostgreSQL|PolarDB 16: 植入通义千问大模型+文本向量化模型, 让数据库具备AI能力
开源大模型非常多, 但都需要大算力才能高效发挥大模型能力, 训练专业大模型. 普通企业很难构建及训练大模型. 为让大模型普惠企业及大众需求, 阿里云推出DashScope灵积:模型集市, 每个模型独有特点, 每一种模型都提供API接口, 任何人都可以调用大模型的算力. 什么和大模型结合将发挥重大的价值? 毫无疑问是数据. 1、通过数据来训练大模型. 2、通过大模型分析数据, 帮助企业进行决策. 3、通过大模型理解数据, 例如帮助企业解决客户和伙伴提出的问题, 提升产品体验. 这个实验将带领大家来体验一下如何将“千问大模型+文本向量化模型”植入到PG|PolarDB中, 让数据库具备AI能力.
23221 18
沉浸式学习PostgreSQL|PolarDB 16: 植入通义千问大模型+文本向量化模型, 让数据库具备AI能力
|
6月前
|
存储 关系型数据库 数据库
数据库内核那些事|PolarDB X-Engine:如何构建1/10成本的事务存储引擎?
X-Engine引擎是PolarDB为用户提供的低成本,高性价比的解决方案,LSM-tree分层存储结合标准zstd压缩,在性能和成本做到了很好的平衡。在标准sysbench场景下,存储空间相比InnoDB引擎减少60%,读写性能降低10-20%。
数据库内核那些事|PolarDB X-Engine:如何构建1/10成本的事务存储引擎?
|
8月前
|
关系型数据库 PostgreSQL
PostgreSQL事务提交日志与CLOG操作初步认识
PostgreSQL事务提交日志与CLOG操作初步认识
121 0
|
9月前
|
Oracle 关系型数据库 数据库
PostgreSQL技术大讲堂 - 第20讲:事务概述与隔离级别
PostgreSQL从小白到专家,技术大讲堂 - 第20讲:事务概述与隔离级别
169 2
|
SQL 缓存 运维
PostgreSQL 事务号回卷分析
## XID 定义 xid 是个啥东西?xid 就是 PostgreSQL 里面的事务号,每个事物都会分配一个 xid。PostgreSQL 数据中每个元组头部都会保存着 插入 或者 删除 这条元组的事务号,即 xid,然后内核通过这个 xid 进行元组的可见性判断。简单理解,比如有两个事务,xid1=200,xid2=201,那么 xid1 中只能看到 t_xmin 200 的元组。 ```c
|
存储 SQL 关系型数据库
【学习资料】第16期快速入门PostgreSQL应用开发与管理 - 6 事务和锁
大家好,这里是快速入门PostgreSQL应用开发与管理 - 6 事务和锁
|
存储 缓存 Dubbo
如何实现事务原子性?PolarDB原子性深度剖析
在巍峨的数据库大厦体系中,查询优化器和事务体系是两堵重要的承重墙,二者是如此重要以至于整个数据库体系结构设计中大量的数据结构、机制和特性都是围绕着二者搭建起来的。他们一个负责如何更快的查询到数据,更有效的组织起底层数据体系;一个负责安全、稳定、持久的存储数据,为用户的读写并发提供逻辑实现。我们今天探索的主题是事务体系,然而事务体系太过庞大,我们需要分成若干次的内容。本文就针对PolarDB事务体系中的原子性进行剖析。
如何实现事务原子性?PolarDB原子性深度剖析