当我在一个表上运行vacuum verbose时，结果显示最旧的xmin值9696975，如下所示：
table_xxx: found 0 removable, 41472710 nonremovable row versions in 482550 out of 482550 pages
DETAIL: 41331110 dead row versions cannot be removed yet, oldest xmin: 9696975
There were 0 unused item identifiers.但是当我签入pg_stat_activity时，没有任何条目的backend_xmin值与这个最旧的xmin值匹配。下面是我运行查询时得到的响应：
SELECT backend_xmin
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL
ORDER BY age(backend_xmin) DESC;答复：
backend_xmin
------------
10134695
10134696
10134696
10134696
10134696我面临的问题是真空没有从表中删除任何死元组。我尝试了中提到的方法：this post但没用
**edit：**Aurora集群运行的PostgreSQL版本为13.6。
2条答案
按热度按时间rryofs0p1#
除了
backend_xmin之外，还要从pg_stat_activity检查backend_xid。具有事务ID的事务也可以阻止VACUUM进程。除了旧的交易，还有一些其他的东西可以阻止“xmin horizon”：
pg_replication_slots）pg_prepared_xacts）hot_standby_feedback = on备用服务器（参见pg_stat_replication中的backend_xmin）有关详细信息，请参阅my article on the topic。
rqenqsqc2#
只有当没有活动事务可以看到它时，一行才完全死了。即在更新/删除该行之前已经启动的事务没有仍然在运行。这根本不一定涉及任何锁。仅仅存在长时间运行的事务就可以阻止
VACUUM清理。所以要查看的系统视图是
pg_stat_activity。查找可以杀死的僵尸事务。然后VACUUM可以继续。旧的已准备交易也会因为同样的原因而被阻止。您可以检查
pg_prepared_xacts。当然，
VACUUM只在主服务器上运行，而不是在副本（备用）示例上运行--如果已经设置了流复制的话。相关：