PostgreSQL中的VACUUM命令

作者：瀚高PG实验室 （Highgo PG Lab）

每当PostgreSQL数据库中的表中的行被更新或删除时，死亡行会被遗留下来。VACUUM则会把它们除去来使空间能被重新利用。如果一个表没有被清空，它会变得臃肿，浪费磁盘空间而且会降低顺序表扫描的速度，而且在较小范围内也会降低索引扫描的速度。

VACUUM命令只可以移除这些不再被需要的行版本（也被称为元组）。如果被删除事务的事务ID（存储在xmax系统列中）比仍然活跃在PostgreSQL数据库（或者共享表的整个集群）中最老的事务（xmin界限）更老，那么这个元组将不再被需要。

注意以下三种情况就可以抑制PostgreSQL集群中的xmin界限：

1、 查找长时间运行的事务

我们可以查找长时间运行的事务，然后使用pg_terminate_backend()函数去终止阻碍VACUUM命令的数据库会话。

2、 查找复制槽

复制槽是一种数据结构，它使PostgreSQL服务器免于丢弃备用服务器仍然需要的信息。如果复制被推迟或者备用服务器被关闭，复制槽就会阻止VACUUM命令删除旧的行。

复制槽提供了一种自动化的方式来确保主服务器不移除WAL块直到它们被所有的从服务器接收。而且主服务器即使当从服务器断开连接时也不移除可能导致恢复冲突的行。

复制槽只保留已知所需数量的WAL块而不是多于所需数量。

使用复制槽可以避免这个问题：在从服务器未连接的任意时间段内不提供保护。

我们可以使用pg_drop_replication_slot()函数去丢弃不需要的复制槽。

这种情况只会发生在当hot_standby_feedback参数设置为on时的物理复制中。如果是逻辑复制，那么会有一个相似的危险，但是只有系统目录会被影响。

3、查找准备好的事务

二阶段提交协议是一种原子性确认协议。它是一种分布式算法，用来协调参与分布式原子事务的所有进程，确定是否提交或者终止（回滚）这个事务。

在二阶段提交过程中，一个分布式事务首先使用PREPARE TRANSACTION，为二阶段提交准备当前事务。如果由于任何原因PREPARE TRANSACTION 命令失败，会变成ROLLBACK，而当前事务则会被取消。

然后我们使用COMMIT PREPARED，提交一个之前为两阶段提交预备的事务。

一旦一个事务被准备好，它会一直保持一种“游荡”状态直到被提交或者中止。通常情况下，事务不会在准备状态中保持很长时间，但有时会出现错误所以事务必须被管理员手动移除。

我们也可以使用ROLLBACK PREPARED，取消一个之前为两阶段提交准备好的事务。