最古老的 xmin 已成为过去 - Postgresql 9.4.4答案

【问题标题】：oldest xmin is far in the past - Postgresql 9.4.4最古老的 xmin 已成为过去 - Postgresql 9.4.4
【发布时间】：2020-04-23 16:46:01
【问题描述】：

我在生产环境中有一个 postgresql 9.4.4。自 3 周以来，我在 pg_log 中收到了很多消息：

<:::2020-04-06 23:59:59 BRT::2020-04-06 23:59:55 BRT:72350>|LOG:  automatic vacuum of table "template0.pg_catalog.pg_range": index scans: 0
    pages: 0 removed, 1 remain
    tuples: 0 removed, 6 remain, 0 are dead but not yet removable
    buffer usage: 20 hits, 0 misses, 0 dirtied
    avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
    system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
<:::2020-04-07 00:00:00 BRT::2020-04-06 23:59:59 BRT:72428>|WARNING:  oldest xmin is far in the past
<:::2020-04-07 00:00:00 BRT::2020-04-06 23:59:59 BRT:72428>|HINT:  Close open transactions soon to avoid wraparound problems.

警告在一天中出现很多次，并且看起来像是在 template0.pg_catalog 的每个表中发生在真空中。

搜索其他堆栈溢出问题，我找到了很多答案，但没有一个适合我的情况。

他们说这可能是三件事：

事务空闲长时间运行：

运行 select * from pg_stat_activity where state = 'idle in transaction'，我只得到一个处于此状态的连接，并且它今天已打开。

未关闭的已准备交易交易

运行 select * from pg_prepared_xacts;，我得到了 9 行，并以 ROLLBACK PREPARED 'gid'; 结束了所有人。所以，我现在没有任何准备好的交易。

未使用的复制槽

运行 select * from pg_replication_slots，我只得到了一行，并且此复制正在另一台服务器中使用。

slot_name;plugin;slot_type;datoid;database;active;xmin;catalog_xmin;restart_lsn
replica;;physical;;;t;2845561097;;584C/CC6604F0

所以，我不能放弃这个，因为它正在使用中。我的两台服务器运行正常，除了日志中的这些消息。

My server:
autovacuum = on 
archive_mode = on
wal_keep_segments = 20
max_wal_senders = 3
max_replication_slots = 3
wal_level = hot_standby
hot_standby = on
archive_command = 'test -f %p && cp %p /opt/postgres/archxlog/%f'

我的 recovery.conf（在另一台服务器上，带有备用复制）：

standby_mode = 'on'
primary_conninfo = 'user= host= port= sslmode=disable sslcompression=1'
primary_slot_name = 'replica'

感谢您的帮助！

编辑：

在谷歌上搜索，我找到了这个网站： http://micronetinternational.com/index.pl/en/00/https/postgrespro.com/list/thread-id/1556972

他们说问题与流式传输中未决的子事务有关。

查看pg_subtrans文件夹，发现好多这么老的文件。

ls -lha | more
total 1,4G
drwx------.  2 postgres postgres  92K Abr 27 10:56 .
drwx------. 19 postgres postgres 4,0K Fev 21 16:38 ..
-rw-------   1 postgres postgres 256K Dez 11 11:07 A99B
-rw-------   1 postgres postgres 256K Dez 11 11:07 A99C
-rw-------   1 postgres postgres 256K Dez 11 11:07 A99D
-rw-------   1 postgres postgres 256K Dez 11 11:07 A99E

我的复制时间大约是今年 2 月。因此，这些文件不是最新的。清除此文件夹的最佳方法是什么？

【问题讨论】：

可能与您的问题无关，但是：Postgres 9.4 是no longer supported，您应该尽快计划升级。而且您至少应该使用最新的 9.4，即 9.4.25 并且具有 over 600 bugfixes
请发布select * from pg_prepared_xacts; 的输出：如果此视图中有行，则意味着您仍有准备好的事务等待完成，因为如果事务已完成，则应删除行（ROLLBACK PREPARED 确实并不意味着 ROLLBACK 已经完成）。
手动在桌子上运行VACUUM (FREEZE, VERBOSE) 是否得到相同的结果？
你好@a_horse_with_no_name ！是的，我们已经计划更新此服务器。但我认为那无关紧要。你好@pifor，我已经做好了回滚准备，所以我现在在这个视图中没有任何线条。交易可以存在于其他地方吗？ @paurenz，由于我无法在 template0 中连接，我无法执行 VACUUM (FREEZE, VERBOSE)。我可以用其他方式吗？

标签： postgresql replication database-replication postgresql-9.4

【解决方案1】：

我设法解决了这个问题；

我停止了复制并删除了复制槽。当我这样做时，pg_subtrans 被清理了，警告消失了。

但是，我失去了复制，不得不从头开始。

现在一切正常。

谢谢大家！

【讨论】：