数据库
首页 > 数据库> > PostgreSQL的MVCC(3)--Row Versions

PostgreSQL的MVCC(3)--Row Versions

作者:互联网

我们已经讨论过隔离,并且对底层数据结构做了介绍。现在介绍一下行版本(元组)。

Tuple header

如前所述,数据库中同一行记录在同一时刻可以有多个版本可用。我们需要以某种方式将一个版本与另一个版本区分开。为此,每个版本都标有有效的“time”(xmin)和到期的”time”(xmax)。引号表示使用特殊的递增计数器,而不是时间本身。该计数器是事务标识符。

(通常,实际中更复杂:由于计数器的bit深度有限,事务ID不能总是递增。但是,当我们的讨论陷入僵局时,我们将探索其更多细节。)

创建行时,将xmin的值设置为等于执行INSERT命令的事务的ID,而未填写xmax。

删除一行后,当前版本的xmax值将标记为执行DELETE的事务的ID。

UPDATE命令实际上执行两个后续操作:DELETE和INSERT。在该行的当前版本中,将xmax设置为等于执行UPDATE的事务的ID。然后,创建同一行的新版本,其中xmin的值与先前版本的xmax相同。

xmin和xmax字段包含在行版本的header中。除这些字段外,tuple header还包含其他字段,例如:

·infomask —占用几个bits,用于确定给定元组的属性。后面我们将逐步讨论。

·ctid—对同一行的下一个更新版本的引用。最新的行版本的ctid引用该版本。 该数字采用(x,y)形式,其中x是页面的编号,而y是数组中指针的顺序号。

·NULL位图,用于标记给定版本中包含NULL的列。NULL不是常规的数据类型值,因此,我们必须单独存储此特征。

因此,header看起来非常大:每个元组至少23个字节,但是由于NULL位图而通常更大。如果一个表是“ narrow”(窄)(也就是说,它包含几列),那么开销字节会比有用信息占用更多的空间。

插入(insert)

让我们更详细地了解如何在底层执行对行的操作,我们从插入开始。

为了进行实验,我们将创建一个有两列的新表,其中一列上有一个索引:

=> CREATE TABLE t(
  id serial,
  s text
);
=> CREATE INDEX ON t(s);

启动一个事务插入一行:

=> BEGIN;
=> INSERT INTO t(s) VALUES ('FOO');

我们当前事务的id是:

=> SELECT txid_current();
 txid_current 
--------------
         3664
(1 row)

让我们看看这个页面的内容。来自«pageinspect»扩展的heap_page_items函数使我们能够获得关于指针和行版本的信息:

=> SELECT * FROM heap_page_items(get_raw_page('t',0)) \gx
-[ RECORD 1 ]-------------------
lp          | 1
lp_off      | 8160
lp_flags    | 1
lp_len      | 32
t_xmin      | 3664
t_xmax      | 0
t_field3    | 0
t_ctid      | (0,1)
t_infomask2 | 2
t_infomask  | 2050
t_hoff      | 24
t_bits      | 
t_oid       | 
t_data      | \x0100000009464f4f

注意,PostgreSQL中的单词«heap»表示表。这是该术语的另一种奇怪用法:堆是一种已知的数据结构,与表无关。这个词在这里使用的意义是«所有都被堆积起来»,不像在有序索引中。

这个函数以一种难以理解的格式显示«当前»数据。为了澄清问题,我们只留下部分信息并加以解释:

=> SELECT '(0,'||lp||')' AS ctid,
       CASE lp_flags
         WHEN 0 THEN 'unused'
         WHEN 1 THEN 'normal'
         WHEN 2 THEN 'redirect to '||lp_off
         WHEN 3 THEN 'dead'
       END AS state,
       t_xmin as xmin,
       t_xmax as xmax,
       (t_infomask & 256) > 0  AS xmin_commited,
       (t_infomask & 512) > 0  AS xmin_aborted,
       (t_infomask & 1024) > 0 AS xmax_commited,
       (t_infomask & 2048) > 0 AS xmax_aborted,
       t_ctid
FROM heap_page_items(get_raw_page('t',0)) \gx
-[ RECORD 1 ]-+-------
ctid          | (0,1)
state         | normal
xmin          | 3664
xmax          | 0
xmin_commited | f
xmin_aborted  | f
xmax_commited | f
xmax_aborted  | t
t_ctid        | (0,1)

我们做了以下工作:

·在指针编号上添加了零,使其看起来像t_ctid :(页面编号,指针编号)。
·解释了lp_flags指针的状态。这里是«normal»,这意味着指针实际上引用了行版本。稍后我们将讨论其他值。
·到目前为止,在所有信息位(bits)中,我们仅选择了两对。xmin_committed和xmin_aborted位显示ID为xmin的事务是否已提交(回滚)。一对相似的位与事务ID的xmax有关。

我们观察到什么?当插入一行时,在表页面中会出现一个指针,该指针的编号为1,并引用该行的第一个且唯一版本。

元组中的xmin字段填充为当前事务的ID。由于事务仍处于活动状态,因此xmin_committed和xmin_aborted位均未设置。

行版本的ctid字段引用同一行。这意味着没有新版本可用。

由于没有删除元组(即最新),因此xmax字段用常规数字0填充。由于设置了xmax_aborted位,事务将忽略该数字。

通过将信息位附加到事务ID上,我们又向前迈出了一步,以提高可读性。并且创建函数,因为我们将多次查询:

=> CREATE FUNCTION heap_page(relname text, pageno integer)
RETURNS TABLE(ctid tid, state text, xmin text, xmax text, t_ctid tid)
AS $$
SELECT (pageno,lp)::text::tid AS ctid,
       CASE lp_flags
         WHEN 0 THEN 'unused'
         WHEN 1 THEN 'normal'
         WHEN 2 THEN 'redirect to '||lp_off
         WHEN 3 THEN 'dead'
       END AS state,
       t_xmin || CASE
         WHEN (t_infomask & 256) > 0 THEN ' (c)'
         WHEN (t_infomask & 512) > 0 THEN ' (a)'
         ELSE ''
       END AS xmin,
       t_xmax || CASE
         WHEN (t_infomask & 1024) > 0 THEN ' (c)'
         WHEN (t_infomask & 2048) > 0 THEN ' (a)'
         ELSE ''
       END AS xmax,
       t_ctid
FROM heap_page_items(get_raw_page(relname,pageno))
ORDER BY lp;
$$ LANGUAGE SQL;

行版本的header更清楚的形式:

=> SELECT * FROM heap_page('t',0);
 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3664 | 0 (a) | (0,1)
(1 row)

通过使用xmin和xmax伪列,我们可以从表本身获得类似的信息,但远没有那么详细:

=> SELECT xmin, xmax, * FROM t;
 xmin | xmax | id |  s  
------+------+----+-----
 3664 |    0 |  1 | FOO
(1 row)

提交(commit)

事务成功后,必须记住其状态,即必须将事务标记为已提交。为此,使用了XACT结构。(在版本10之前,它被称为CLOG(提交日志),仍然很可能会遇到此名称)

XACT不是系统目录的表,而是PGDATA /pg_xact目录中的文件。在这些文件中为每个事务分配了两个bits(即«committed»和«aborted»),其方式与元组头中的方式完全相同。此信息只是为了方便而散布在几个文件中。在讨论freezing时,我们将回到这一点。PostgreSQL与所有其他文件一样,逐页处理这些文件。

因此,提交事务后,将在XACT中为此事务设置“ committed”位。这就是提交事务时发生的所有事情(尽管我们还没有提到预写日志)。

当其他事务访问我们刚刚查看的表页面时,前者将不得不回答一些问题:

1.事务xmin是否已完成? 如果没有,则创建的元组必须不可见。通过查看位于实例的共享内存中的另一个结构ProcArray来检查此情况。此结构包含所有活动进程的列表,以及每个进程的当前(活动)事务的ID。

2.如果事务完成,那么是提交还是回滚? 如果已回滚,则该元组也不得可见。这正是为什么需要XACT。但是,尽管XACT的最后一页存储在共享内存的缓冲区中,但每次检查XACT的开销都很高。 因此,一旦确定了事务状态,就将其写入元组的xmin_committed和xmin_aborted位。如果设置了这些位中的任何一个,则将事务状态视为已知,并且下一个事务将不需要检查XACT。

为什么执行插入的事务未设置这些位? 当执行插入操作时,事务尚不知道它是否将成功完成。在提交时,还不清楚哪些行和哪些页面已更改。这样的页面可能很多,要跟踪它们是不切实际的。此外,某些页面可能从缓冲区高速缓存中被逐出到磁盘上。再次读取它们以更改位将意味着提交的速度大大降低。

节省成本的反面是,更新之后,任何事务(甚至是执行SELECT的事务)都可以开始更改缓冲区高速缓存中的数据页。

因此,我们提交更改:

=> COMMIT;

页面中没有任何更改(但我们知道事务状态已经写入XACT):

=> SELECT * FROM heap_page('t',0);
 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3664 | 0 (a) | (0,1)
(1 row)

现在,第一次访问该页面的事务将需要确定事务xmin的状态,并将其写入信息位(bit):

=> SELECT * FROM t;
 id |  s  
----+-----
  1 | FOO
(1 row)

=> SELECT * FROM heap_page('t',0);
 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3664 (c) | 0 (a) | (0,1)
(1 row)

删除(delete)

当删除一行时,当前删除事务的ID会写入最新版本的xmax字段,并且xmax_aborted位将被重置。

请注意,与活动事务相对应的xmax值用作行锁。如果另一个事务要更新或删除该行,则必须等到xmax事务完成。稍后我们将更详细地讨论锁。此时,仅注意行锁的数量根本没有限制。它们不占用内存,并且该数量不会影响系统性能。但是,长时间的事务还有其他缺点,稍后将对此进行讨论。

让我们删除一行。

=> BEGIN;
=> DELETE FROM t;
=> SELECT txid_current();
 txid_current 
--------------
         3665
(1 row)

我们看到事务ID被写到xmax字段,但是信息位未被设置:  

=> SELECT * FROM heap_page('t',0);
 ctid  | state  |   xmin   | xmax | t_ctid 
-------+--------+----------+------+--------
 (0,1) | normal | 3664 (c) | 3665 | (0,1)
(1 row)

中止(abort)

事务的Abort与commit的工作原理类似,只是«aborted»位是在XACT中设置的。中止和提交一样快。尽管该命令被称为ROLLBACK,但更改不会回滚:事务已经更改的所有内容将保持不变。

=> ROLLBACK;
=> SELECT * FROM heap_page('t',0);
 ctid  | state  |   xmin   | xmax | t_ctid 
-------+--------+----------+------+--------
 (0,1) | normal | 3664 (c) | 3665 | (0,1)
(1 row)

当访问页面时,状态将被检查,提示位xmax_aborted将被设置。虽然数字xmax本身仍然在页面中,但是它不会被查看。

=> SELECT * FROM t;
 id |  s  
----+-----
  1 | FOO
(1 row)

=> SELECT * FROM heap_page('t',0);
 ctid  | state  |   xmin   |   xmax   | t_ctid 
-------+--------+----------+----------+--------
 (0,1) | normal | 3664 (c) | 3665 (a) | (0,1)
(1 row)

更新(update)

更新的工作原理是先删除当前版本,然后再插入新版本。

=> BEGIN;
=> UPDATE t SET s = 'BAR';
=> SELECT txid_current();
 txid_current 
--------------
         3666
(1 row)

查询返回一行(新版本):

=> SELECT * FROM t;
 id |  s  
----+-----
  1 | BAR
(1 row)

但是我们可以在页面上看到两个版本:

=> SELECT * FROM heap_page('t',0);
 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3664 (c) | 3666  | (0,2)
 (0,2) | normal | 3666     | 0 (a) | (0,2)
(2 rows)

删除的版本在xmax字段中用当前事务的ID标记。而且,自从上一个事务回滚以来,这个值已经覆盖了原来的值。并且xmax_aborted位被重置,因为当前事务的状态还未知。

该行的第一个版本现在引用第二个版本作为更新的行。

索引页现在包含第二个指针和第二行,它引用表页中的第二个版本。

与删除操作相同,第一个版本中的xmax值表示该行被锁定。

最后,我们提交事务:

=> COMMIT;

索引(indexes)

到目前为止,我们仅谈论表页。但是索引内部会发生什么?

索引页中的信息取决于特定的索引类型。而且,即使一种类型的索引也可以具有不同种类的页。例如:B树具有元数据页面和“普通”页面。

但是,索引页通常具有一个指向行和行本身的指针数组(就像表页一样)。此外,页面末尾的一些空间还分配给特殊数据。

根据索引类型,索引中的行也可以具有不同的结构。例如:在B树中,与叶子页相关的行包含索引键的值和对相应表行的引用(ctid)。通常,索引的结构可以完全不同。

要点是,在任何类型的索引中都没有行版本。或者我们可以考虑每一行仅由一个版本表示。换句话说,索引行的header不包含xmin和xmax字段。现在,我们可以假定从索引指向表行的所有版本的引用。因此,要确定事务中可见哪些行版本,PostgreSQL需要查看表。(像往常一样,这不是全部内容。有时可见性视图可以优化流程,但我们稍后会讨论)

在这里,在索引页面中,我们找到两个版本的指针:最新版本和之前版本:

=> SELECT itemoffset, ctid FROM bt_page_items('t_s_idx',1);
 itemoffset | ctid  
------------+-------
          1 | (0,2)
          2 | (0,1)
(2 rows)

(这里,我做过测试,对表执行vacuum full之后,再次查询就只有一条记录了。至于可见性视图优化流程暂时没有测试!!!)

虚拟事务(virtual transactions)

实际上,PostgreSQL利用了优化的优势,该优化允许“少量”消耗事务ID。

如果事务仅读取数据,则根本不影响元组的可见性。 因此,首先,后端进程将虚拟ID(虚拟xid)分配给事务。该ID由进程标识符和序列号组成。

分配此虚拟ID不需要所有进程之间的同步,因此可以非常快速地执行。 在讨论freezing时,我们将了解使用虚拟ID的另一个原因。

数据快照根本不考虑虚拟ID。

在不同的时间点,系统可以使用已经使用过的id进行虚拟事务,这很好。但是这个ID不能写入数据页,因为当下一次访问该页时,这个ID可能会变得毫无意义。

=> BEGIN;
=> SELECT txid_current_if_assigned();
 txid_current_if_assigned 
--------------------------
                         
(1 row)

但是,如果事务开始更改数据,它将接收一个真实的、惟一的事务ID。

=> UPDATE accounts SET amount = amount - 1.00;
=> SELECT txid_current_if_assigned();
 txid_current_if_assigned 
--------------------------
                     3667
(1 row)

=> COMMIT;

  

 

子事务(Subtransactions)

检查点(savepoints)

在SQL中,定义了savepoint,这些保存点允许回滚事务的某些操作而不会完全中止。但这与上述模型不兼容,因为事务状态是所有更改的结果之一,并且没有物理回滚的数据。

为了实现此功能,带有保存点的事务被分为几个单独的子事务,其状态可以分别进行管理。

子事务具有自己的ID(大于主事务的ID)。子事务的状态以通常的方式写入XACT,但最终状态取决于主事务的状态:如果回滚,则所有子事务也将回滚。

有关子事务嵌套的信息存储在PGDATA/pg_subtrans目录的文件中。这些文件是通过实例共享内存中的缓冲区访问的,这些缓冲区的结构与XACT缓冲区相同。

不要将子事务与匿名事务混淆。匿名事务绝不相互依赖,而子事务却相互依赖。常规PostgreSQL中没有匿名事务:实际上很少需要它们,并且它们在其他DBMS中的可用性会导致滥用,每个人都会遭受痛苦。

让我们清除表,开始事务并插入一行:

=> TRUNCATE TABLE t;
=> BEGIN;
=> INSERT INTO t(s) VALUES ('FOO');
=> SELECT txid_current();
 txid_current 
--------------
         3669
(1 row)

=> SELECT xmin, xmax, * FROM t;
 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
(1 row)

=> SELECT * FROM heap_page('t',0);
 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3669 | 0 (a) | (0,1)
(1 row)

现在我们建立一个保存点并插入另一行:

=> SAVEPOINT sp;
=> INSERT INTO t(s) VALUES ('XYZ');
=> SELECT txid_current();
 txid_current 
--------------
         3669
(1 row)

请注意,txid_current函数返回主事务的ID,而不是子事务的ID。

=> SELECT xmin, xmax, * FROM t;
 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
 3670 |    0 |  3 | XYZ
(2 rows)

=> SELECT * FROM heap_page('t',0);
 ctid  | state  | xmin | xmax  | t_ctid 
-------+--------+------+-------+--------
 (0,1) | normal | 3669 | 0 (a) | (0,1)
 (0,2) | normal | 3670 | 0 (a) | (0,2)
(2 rows)

让我们回滚到保存点并插入第三行:

=> ROLLBACK TO sp;
=> INSERT INTO t VALUES ('BAR');
=> SELECT xmin, xmax, * FROM t;
 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
 3671 |    0 |  4 | BAR
(2 rows)

=> SELECT * FROM heap_page('t',0);
 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3669     | 0 (a) | (0,1)
 (0,2) | normal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normal | 3671     | 0 (a) | (0,3)
(3 rows)

在该页中,我们继续看到回滚子事务添加的行。

提交更改:

=> COMMIT;
=> SELECT xmin, xmax, * FROM t;
 xmin | xmax | id |  s  
------+------+----+-----
 3669 |    0 |  2 | FOO
 3671 |    0 |  4 | BAR
(2 rows)

=> SELECT * FROM heap_page('t',0);
 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3669 (c) | 0 (a) | (0,1)
 (0,2) | normal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normal | 3671 (c) | 0 (a) | (0,3)
(3 rows)

现在可以清楚地看到,每个子事务都有自己的状态。

注意,SQL不允许显式使用子事务,也就是说,在完成当前事务之前不能启动新事务。在使用保存点、处理PL/pgSQL异常以及其他一些更奇怪的情况下,这种技术会隐式地涉及到。

=> BEGIN;
BEGIN
=> BEGIN;
WARNING:  there is already a transaction in progress
BEGIN
=> COMMIT;
COMMIT
=> COMMIT;
WARNING:  there is no transaction in progress
COMMIT

 

错误和原子性操作

如果在执行操作时发生错误,会发生什么?例如,像这样:

=> BEGIN;
=> SELECT * FROM t;
 id |  s  
----+-----
  2 | FOO
  4 | BAR
(2 rows)

=> UPDATE t SET s = repeat('X', 1/(id-4));
ERROR:  division by zero

一个错误发生。现在事务被视为中止,不允许任何操作:

=> SELECT * FROM t;
ERROR:  current transaction is aborted, commands ignored until end of transaction block

即使我们尝试提交更改,PostgreSQL也会报告回滚:

=> COMMIT;
ROLLBACK

为什么失败后无法继续执行事务? 问题是可能发生错误,以至我们可以访问部分更改,也就是说,不仅对于事务,甚至对于单个操作,原子性都将被破坏。例如,在我们的示例中,操作可以在发生错误之前更新一行:

=> SELECT * FROM heap_page('t',0);
 ctid  | state  |   xmin   | xmax  | t_ctid 
-------+--------+----------+-------+--------
 (0,1) | normal | 3669 (c) | 3672  | (0,4)
 (0,2) | normal | 3670 (a) | 0 (a) | (0,2)
 (0,3) | normal | 3671 (c) | 0 (a) | (0,3)
 (0,4) | normal | 3672     | 0 (a) | (0,4)
(4 rows)

值得注意的是,psql有一种模式,它允许在失败后继续事务,就像错误操作符的影响被回滚一样。

=> \set ON_ERROR_ROLLBACK on
=> BEGIN;
=> SELECT * FROM t;
 id |  s  
----+-----
  2 | FOO
  4 | BAR
(2 rows)

=> UPDATE t SET s = repeat('X', 1/(id-4));
ERROR:  division by zero

=> SELECT * FROM t;
 id |  s  
----+-----
  2 | FOO
  4 | BAR
(2 rows)

=> COMMIT;

很容易看出,在这种模式下,psql实际上在每个命令之前建立一个隐式保存点,并在失败时对其发起回滚。默认情况下不使用此模式,因为建立保存点(即使不回滚保存点)会带来很大的开销。

 

 

原文地址:

https://habr.com/en/company/postgrespro/blog/477648/

标签:事务,PostgreSQL,normal,--,xmax,xmin,ctid,SELECT,Row
来源: https://www.cnblogs.com/abclife/p/13524044.html