postgresql PSQL:VACUUM ANALYZE显示不正确的最旧xmin

3qpi33ja  于 2023-04-20  发布在  PostgreSQL
关注(0)|答案(2)|浏览(214)

当我在一个表上运行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。

rryofs0p

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

rqenqsqc

rqenqsqc2#

只有当没有活动事务可以看到它时,一行才完全死了。即在更新/删除该行之前已经启动的事务没有仍然在运行。这根本不一定涉及任何锁。仅仅存在长时间运行的事务就可以阻止VACUUM清理。
所以要查看的系统视图是pg_stat_activity。查找可以杀死的僵尸事务。然后VACUUM可以继续。
旧的已准备交易也会因为同样的原因而被阻止。您可以检查pg_prepared_xacts
当然,VACUUM只在主服务器上运行,而不是在副本(备用)示例上运行--如果已经设置了流复制的话。
相关:

相关问题