PostgreSQL 14 新特性两阶段routines和两阶段提交

PostgreSQL14中支持不锁表的情况下去detach分区。
语法为 ALTER TABLE … DETACH PARTITION … CONCURRENTLY, and FINALIZE。

这个操作是基于pg14中的两阶段routines管理机制来实现的，alter table 支持两阶段 routine 管理，这使得将来某些需要rewrite整张表的操作将不再锁表(或者短暂加锁)。

例如当前vacuum full是全程排它锁，而通过这个两阶段routines管理机制，将来可能不会锁表了。

这一特性和pg中的两阶段提交很相似，这里我们看看pg中两阶段提交是如何实现的。

两阶段提交：

首先我们简单介绍下什么是两阶段提交，这个在我们pg中一般不常用到，因为在一般的关系型数据库中可以很简单的保证事务的ACID，但是在分布式事务中的实现并不是那么轻松，因此就用到了我们要说的两阶段提交。

两阶段提交简单来说就是将事务分为两个阶段：投票阶段、事务提交/回滚。

而在PostgreSQL中大致过程如下：

1. 应用程序先调用各台机数据库做一些操作，但不提交事务。然后应用程序调用事务协调器（这个协调器可能也是由应用自己实现）中的提交方法。
2. 事务协调器将联络事务中涉及的每台数据库，并通知它们准备提交事务，这是第一阶段的开始。在PostgreSQL一般是调用“PREPARE
   TRANSACTION”命令。
3. 各台数据库接收到“PREPARE
   TRANSACTION”命令后，如果要返回成功，则数据库必须将自己置于以下状态：确保能在被要求提交事务时提交事务，或在被要求回滚事务时回滚事务。所以PostgreSQL会将已准备好提交的信息写入持久存储区中。如果数据库无法完成此事务，它会直接返回失败给事务协调器。
4. 事务协调器接收到了所有数据库的响应。
5. 在第二阶段，如果任一数据库在第一阶段返回失败，则事务协调器会将发一个回滚命令（ROLLBACK
   PREPARED）给各台数据库。如果所有数据库的响应都是成功的，则向各台数据库发送“COMMIT
   PREPARED”命令，通知各台数据库事务成功。

下面我们通过例子来看看pg中的两阶段提交如何实现。

首先，我们需要设置“max_prepared_transactions”参数为一个大于0的数，且这个参数修改后要重启数据库。

在postgresql.conf中设置该参数：

max_prepared_transactions = 10

启动一个事务：

bill@bill=>begin ;
BEGIN
bill@bill=>insert into t1 values(1,'bill');
INSERT 0 1

使用PREPARE TRANSACTION命令来代表两阶段提交的第一阶段：

bill@bill=>PREPARE TRANSACTION 'tras1';
PREPARE TRANSACTION

查看：

bill@bill=>select * from pg_prepared_xacts;
 transaction |  gid  |           prepared            | owner | database
-------------+-------+-------------------------------+-------+----------
        2760 | tras1 | 2021-05-17 19:28:22.164008+08 | bill  | bill
(1 row)

PREPARE TRANSACTION执行之后，这个事务不再与当前会话关联，会由事务协调器将该session做过的操作持久化。

这里我们即使重启数据库也不会丢失该数据。

pg_ctl stop
pg_ctl start

重启完之后再提交该事务，可以看到刚刚事务中插入的记录。

bill@bill=>select * from t1;
 id | info
----+------
(0 rows)

bill@bill=>COMMIT PREPARED 'tras1';
COMMIT PREPARED

bill@bill=>select * from t1;
 id | info
----+------
  1 | bill
(1 row)