PostgreSQL VACUUM 没有效果无法清理死元组的原因

众所周知，在Postgresql里面使用VACUUM FULL来回收dead tuples空间并将其返回给操作系统。但是我执行VACUUM FULL却没有任何效果，是数据库版本出现了bug？当然不是！
经排查原来是Physical Replication Slot导致（具体解释见http://mysql.taobao.org/monthly/2015/02/03/）。将hot_standby_Feedback设为on时，从库关闭，主库的xmin不再改变，主库的vaccum操作停滞，造成主库被频繁更新的表大小暴增。

为什么VACUUM不清理死元组？

VACUUM只能删除不再需要的那些行版本（也称为“元组”）。如果删除事务的事务 ID（存储在xmax中）早于 Postgresql 数据库（或共享表的整个集群）中仍处于活动状态的最旧事务，则无法清除元组。

在 Postgresql 集群中，有三件事可以阻止这个VACUUM回收死元组：

1. 长时间运行的事务：

   可以通过以下查询找到长时间运行的事务及其xmin值：

   SELECT pid, datname, usename, state, backend_xmin
   FROM pg_stat_activity
   WHERE backend_xmin IS NOT NULL
   ORDER BY age(backend_xmin) DESC;

   可以使用该pg_terminate_backend()函数来终止阻止您的VACUUM.

2. 废弃的Replication Slot：

   复制槽是一种数据结构，保持从主库丢弃但仍需要由备用服务器赶上主要信息Postgresql服务器的数据。

   如果复制延迟或备用服务器关闭，复制槽将阻止VACUUM删除旧行。

   可以使用此查询找到所有复制槽及其xmin值：

   SELECT slot_name, slot_type, database, xmin
   FROM pg_replication_slots
   ORDER BY age(xmin) DESC;

   使用该pg_drop_replication_slot()函数删除不再需要的复制槽。

   注意：如果hot_standby_Feedback = on. 对于逻辑复制存在类似的危险（无法回收元组），但只有系统目录受到影响。catalog_xmin在这种情况下检查列。

3. 孤立的准备运行的事务：

   在两阶段提交期间，分布式事务首先用PREPARE语句准备，然后用COMMIT PREPARED语句提交。

   一旦一个事务准备好，它就会一直“等待”直到它被提交或中止。它甚至必须在服务器重启后还需要保留下来！通常，事务不会长时间保持准备状态，但有时会出错，必须由管理员手动删除准备好的事务。

   可以xmin使用以下查询找到所有准备好的交易及其价值：

   SELECT gid, prepared, owner, database, transaction AS xmin
   FROM pg_prepared_xacts
   ORDER BY age(transaction) DESC;

   使用ROLLBACK PREPAREDsql 语句删除准备好的事务。