Postgresql 探索MVCC

张利勇发布于2019-07-25 12:33 / 1823人阅读

摘要：分析对于的自身事务的一定是不可见对于自身事务的并且已经提交的事务可见除外对于第一条规则很好判断在自身事务之后的动作一定是看不见的。第二条规则困难一些需要判断一个事务是否提交可能还需判断是否是。

Postgresql MVCC Postgresql的隐藏列

tableoid
是表对象的一个唯一标识符，可以和pg_class中的oid联合起来查看

xmin
是插入的事务标识符,是用来标识不同事务下的一个版本控制

xmax
是删除更新的事务标识符，如果该值不为0，则说明该行数据当前还未提交或回滚

cmin
插入事务的命令标识符,从0开始

cmax
删除事务的命令标识符，或者为0

ctid
是每行数据在表中的一个物理位置标识符

下面举例说明:

t1=# create table test (id integer, value text);
CREATE TABLE
t1=# insert into test values (1, "a"), (2, "aa"), (3, "aaa");
INSERT 0 3
t1=# select cmin,cmax,xmin,xmax,ctid, * from test;
 cmin | cmax |   xmin   | xmax | ctid  | id | value 
------+------+----------+------+-------+----+-------
    0 |    0 | 75066031 |    0 | (0,1) |  1 | a
    0 |    0 | 75066031 |    0 | (0,2) |  2 | aa
    0 |    0 | 75066031 |    0 | (0,3) |  3 | aaa
(3 rows)

 xmin: 75066031 是插入数据的事务id
 xmax: 0 表示已经提交了
 ctid: (0, 1), (0, 2), (0, 3)是tuple 所在table中的位置
 
 t1=# begin;
 BEGIN
 t1=# select tableoid from test;
    tableoid 
 ----------
    96972
    96972
    96972
 (3 rows)

t1=# insert into test values (4, "b");
INSERT 0 1
t1=# insert into test values (5, "bb");
INSERT 0 1
t1=# insert into test values (6, "bbb");
INSERT 0 1
t1=# select cmin,cmax,xmin,xmax,ctid, * from test;
cmin | cmax |   xmin   | xmax | ctid  | id | value 
------+------+----------+------+-------+----+-------
0 |    0 | 75066031 |    0 | (0,1) |  1 | a
0 |    0 | 75066031 |    0 | (0,2) |  2 | aa
0 |    0 | 75066031 |    0 | (0,3) |  3 | aaa
0 |    0 | 75066040 |    0 | (0,4) |  4 | b
1 |    1 | 75066040 |    0 | (0,5) |  5 | bb
2 |    2 | 75066040 |    0 | (0,6) |  6 | bbb
(6 rows)

t1=# commit;
COMMIT

tableoid: 是表的oid

探索postgresql MVCC 原理

首先打开两个psql
t1=# begin;
BEGIN
t1=# select cmin,cmax,xmin,xmax,ctid, * from test;
cmin | cmax |   xmin   | xmax | ctid  | id | value 
------+------+----------+------+-------+----+-------
0 |    0 | 75066031 |    0 | (0,1) |  1 | a
0 |    0 | 75066031 |    0 | (0,2) |  2 | aa
0 |    0 | 75066031 |    0 | (0,3) |  3 | aaa
0 |    0 | 75066040 |    0 | (0,4) |  4 | b
1 |    1 | 75066040 |    0 | (0,5) |  5 | bb
2 |    2 | 75066040 |    0 | (0,6) |  6 | bbb
(6 rows)

t1=# update test set value = "c" where id = 4;
UPDATE 1
t1=# select cmin,cmax,xmin,xmax,ctid, * from test;
cmin | cmax |   xmin   | xmax | ctid  | id | value 
------+------+----------+------+-------+----+-------
0 |    0 | 75066031 |    0 | (0,1) |  1 | a
0 |    0 | 75066031 |    0 | (0,2) |  2 | aa
0 |    0 | 75066031 |    0 | (0,3) |  3 | aaa
1 |    1 | 75066040 |    0 | (0,5) |  5 | bb
2 |    2 | 75066040 |    0 | (0,6) |  6 | bbb
0 |    0 | 75066045 |    0 | (0,7) |  4 | c
(6 rows)
t1=# select txid_current();
txid_current 
--------------
    75066045
(1 row)

从上面的数据可以看出当数据库做一个更新操作时，并不是将老的数据删除，再将新的数据覆盖上去，相反它会把老的数据做一个标记隔离出去，然后再新增新的数据作为一个新的版本

现在看另一个psql
t1=# begin;
BEGIN
t1=# select cmin,cmax,xmin,xmax,ctid, * from test;
 cmin | cmax |   xmin   |   xmax   | ctid  | id | value 
------+------+----------+----------+-------+----+-------
0 |    0 | 75066031 |        0 | (0,1) |  1 | a
0 |    0 | 75066031 |        0 | (0,2) |  2 | aa
0 |    0 | 75066031 |        0 | (0,3) |  3 | aaa
0 |    0 | 75066040 | 75066045 | (0,4) |  4 | b
1 |    1 | 75066040 |        0 | (0,5) |  5 | bb
2 |    2 | 75066040 |        0 | (0,6) |  6 | bbb
(6 rows)


从上面的数据逆推当Update时postgres 至少做三个动作
1. copy olddata to newplace
2. update data
3. add new transaction id to old data xmax

postgresq Delete 会更简单一些只需要在tuple 上做一个标记.

既然postgres不会直接在olddata上修改，又是如何对这些tuple做隔离的呢？ 简而言之postgres 如何判断这些tuple 是否对一个事务可见。
分析:
1. 对于tuple 的 xmin > 自身事务id 的row 一定是不可见
2. 对于tuple xmin < 自身事务id 的row并且已经提交的事务可见(deleted tuple 除外)

对于第一条规则很好判断(在自身事务之后的动作一定是看不见的)。 第二条规则困难一些需要判断一个事务是否提交,（可能还需判断tuple是否是deleted。因为postgresql vacuum 是异步删除deleted tuple）
对于这个问题postgres在tuple的header 里加入一个属性 t_infomask 用于标记transaction的状态.

Extension Pageinspect

select * from pg_available_extensions;
create extension pageinspect;
t1=# begin;
BEGIN
t1=# select cmin,cmax,xmin,xmax,ctid, * from test;
 cmin | cmax |   xmin   | xmax | ctid  | id | value 
------+------+----------+------+-------+----+-------
    0 |    0 | 75066031 |    0 | (0,1) |  1 | a
    0 |    0 | 75066031 |    0 | (0,2) |  2 | aa
    0 |    0 | 75066031 |    0 | (0,3) |  3 | aaa
    1 |    1 | 75066040 |    0 | (0,4) |  5 | bb
    2 |    2 | 75066040 |    0 | (0,5) |  6 | bbb
    0 |    0 | 75066110 |    0 | (0,6) |  4 | b
(6 rows)

t1=# SELECT * FROM heap_page_items(get_raw_page("test", 0));
 lp | lp_off | lp_flags | lp_len |  t_xmin  | t_xmax | t_field3 | t_ctid | t_infomask2 | t_infomask | t_hoff | t_bits | t_oid 
----+--------+----------+--------+----------+--------+----------+--------+-------------+------------+--------+--------+-------
  1 |   8160 |        1 |     30 | 75066031 |      0 |        0 | (0,1)  |           2 |       2818 |     24 |        |      
  2 |   8128 |        1 |     31 | 75066031 |      0 |        0 | (0,2)  |           2 |       2818 |     24 |        |      
  3 |   8096 |        1 |     32 | 75066031 |      0 |        0 | (0,3)  |           2 |       2818 |     24 |        |      
  4 |   8064 |        1 |     31 | 75066040 |      0 |        1 | (0,4)  |           2 |       2818 |     24 |        |      
  5 |   8032 |        1 |     32 | 75066040 |      0 |        2 | (0,5)  |           2 |       2818 |     24 |        |      
  6 |   8000 |        1 |     30 | 75066110 |      0 |        0 | (0,6)  |           2 |      11010 |     24 |        |      
(6 rows)

t1=# update test set value = "c" where id = 4;
UPDATE 1
t1=# SELECT * FROM heap_page_items(get_raw_page("test", 0));
 lp | lp_off | lp_flags | lp_len |  t_xmin  |  t_xmax  | t_field3 | t_ctid | t_infomask2 | t_infomask | t_hoff | t_bits | t_oid 
----+--------+----------+--------+----------+----------+----------+--------+-------------+------------+--------+--------+-------
  1 |   8160 |        1 |     30 | 75066031 |        0 |        0 | (0,1)  |           2 |       2818 |     24 |        |      
  2 |   8128 |        1 |     31 | 75066031 |        0 |        0 | (0,2)  |           2 |       2818 |     24 |        |      
  3 |   8096 |        1 |     32 | 75066031 |        0 |        0 | (0,3)  |           2 |       2818 |     24 |        |      
  4 |   8064 |        1 |     31 | 75066040 |        0 |        1 | (0,4)  |           2 |       2818 |     24 |        |      
  5 |   8032 |        1 |     32 | 75066040 |        0 |        2 | (0,5)  |           2 |       2818 |     24 |        |      
  6 |   8000 |        1 |     30 | 75066110 | 75066121 |        0 | (0,7)  |       16386 |       8962 |     24 |        |      
  7 |   7968 |        1 |     30 | 75066121 |        0 |        0 | (0,7)  |       32770 |      10242 |     24 |        |      
(7 rows)

t1=# select cmin,cmax,xmin,xmax,ctid, * from test;
 cmin | cmax |   xmin   | xmax | ctid  | id | value 
------+------+----------+------+-------+----+-------
    0 |    0 | 75066031 |    0 | (0,1) |  1 | a
    0 |    0 | 75066031 |    0 | (0,2) |  2 | aa
    0 |    0 | 75066031 |    0 | (0,3) |  3 | aaa
    1 |    1 | 75066040 |    0 | (0,4) |  5 | bb
    2 |    2 | 75066040 |    0 | (0,5) |  6 | bbb
    0 |    0 | 75066121 |    0 | (0,7) |  4 | c
(6 rows)

t1=# select txid_current();
 txid_current 
--------------
 75066121
(1 row)

Vacuum internals 文章实在太好了
Postgres Hint Bits

GPU云服务器云服务器 MVCC 深度探索探索探索性

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/38954.html

关系型数据库中的事务管理详解：并发控制与事务日志

摘要：关系型数据库中的事务管理详解并发控制与事务日志数据库系统的萌芽出现于年代。并发控制并发控制旨在针对数据库中对事务并行的场景，保证中的一致性与隔离性。绝大部分数据库会采用锁或者数据版本控制的方式来处理并发控制问题。本文节选自：关系型数据库理论 https://url.wx-coder.cn/DJNQn ，涉及引用/整理的文章列举在了 Database-List。 showImg(htt...

Pink 2019-07-25 12:39 评论0 收藏0
关系型数据库中的事务管理详解：并发控制与事务日志

摘要：关系型数据库中的事务管理详解并发控制与事务日志数据库系统的萌芽出现于年代。并发控制并发控制旨在针对数据库中对事务并行的场景，保证中的一致性与隔离性。绝大部分数据库会采用锁或者数据版本控制的方式来处理并发控制问题。本文节选自：关系型数据库理论 https://url.wx-coder.cn/DJNQn ，涉及引用/整理的文章列举在了 Database-List。 showImg(htt...

haobowd 2019-06-25 19:09 评论0 收藏0

发表评论

登陆后可评论

0条评论

张利勇

男|高级讲师

我要关注我要私信

TA的文章

如何区分网络号和主机号-IP地址的网络号与主机号如何确定？

阅读 6866·2021-09-22 15:36
宝塔Linux面板7.7.0开心版：免费宝塔面板专业版/企业版安装部署教程

阅读 5687·2021-09-02 10:20
微分销系统的优势有哪些？

阅读 1869·2019-08-30 15:44
前端性能优化之gzip

阅读 2653·2019-08-29 14:06
前端实习面试汇总

阅读 1153·2019-08-29 11:17
基于原生JS验证表单组件：xy-form

阅读 1585·2019-08-26 14:05
详解JS错误处理：前端JS/Vue/React/Iframe/跨域/Node

阅读 3092·2019-08-26 13:50
基于Taro与typescript开发的网易云音乐小程序

阅读 1550·2019-08-26 10:26

资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

Postgresql 探索MVCC

探索postgresql MVCC 原理

Extension Pageinspect

相关文章

关系型数据库中的事务管理详解：并发控制与事务日志

关系型数据库中的事务管理详解：并发控制与事务日志

发表评论

0条评论

张利勇

男|高级讲师

TA的文章

如何区分网络号和主机号-IP地址的网络号与主机号如何确定？

宝塔Linux面板7.7.0开心版：免费宝塔面板专业版/企业版安装部署教程

微分销系统的优势有哪些？

前端性能优化之gzip

前端实习面试汇总

基于原生JS验证表单组件：xy-form

详解JS错误处理：前端JS/Vue/React/Iframe/跨域/Node

基于Taro与typescript开发的网易云音乐小程序

最新活动