Question

由于长时间运行的非闲置事务（在某种意义上，实际上是因为由于问题而处于活动状态），我有在大型Postgres 10集群上遇到事务id折回的风险与查询中使用的Cassandra FDW）。我及时发现了问题，并且vacuum freeze的大量使用使一切都可以得到控制……也许。

在数据库级别上一切都很好：

warehouse=# SELECT datname, age(datfrozenxid) FROM pg_database;
  datname  |   age
-----------+----------
 postgres  | 85253797
 template1 | 85253797
 template0 | 85253797
 warehouse | 89423564
 repmgr    | 85253797
(5 rows)

但是我仍然在日志中看到这些内容，并且在复制时遇到了麻烦（目前已禁用，直到问题解决为止）：

WARNING:  oldest xmin is far in the past
HINT:  Close open transactions soon to avoid wraparound problems.

使用该查询查看各种数据库，我看到了一些有关的问题：xid的年龄恰好达到了可环绕的上限，但是对于所有无法vacuum freeze的事物，例如索引，序列，和系统表：

select relname, age from (select relname, age(relfrozenxid) age from pg_class) a order by age desc;
                  relname                  |    age
-------------------------------------------+------------
 user_mappings                             | 2147483647
 pg_stat_sys_indexes                       | 2147483647
 pg_stat_user_indexes                      | 2147483647
 pg_statio_all_indexes                     | 2147483647
 pg_statio_sys_indexes                     | 2147483647
 ...

作为恢复的一部分，有一次重新启动，因为这是清除卡住的查询的唯一方法，因此，我认为我仍然没有像长寿的准备好的语句那样会导致较高的xid，临时表等，所以我不清楚是什么原因引起的。

因此，有关这一切的几个相关问题：

这是一个问题吗（除了生成一堆烦人的错误消息之外）？
我能做些什么吗？
这会干扰复制吗？现在我无法追上副本（总是向我显示有关丢失的WAL的主要错误消息和错误消息源源不断的错误消息）？

Answer 1

您显示的表都是视图，2147483647的年龄仅反映了relfrozenxid的值为0。

视图没有元组，也不需要VACUUM，因此这些都是假阳性。

您能确定引起警告的确切原因吗？

有些东西会阻塞VACUUM并在重启后幸存：复制槽和准备好的事务。

您的复制可能只是落后了，我不认为与事务ID问题有直接关系（但是我不确定，因为您没有显示日志）。

非用户表的Postgres交易ID包装

1 个答案: