由于与 ubuntu 上的 postgresql 中的恢复冲突，pg_dump 在备用服务器取消语句上失败

Question

在我的生产服务器上，有时备份失败并显示以下消息。此备份安排在备用节点上。 （在我的环境中配置了流复制。）在此备份期间没有运行任何进程。这是 Ubuntu 机器上的每晚 cron 作业。

2020-07-01 05:21:07.567 CEST [27925] postgres@DBname LOG:  process 27925 still waiting for AccessShareLock on relation 2610 of database 17948 after 1000.096 ms
2020-07-01 05:21:07.567 CEST [27925] postgres@DBname DETAIL:  Process holding the lock: 25802. Wait queue: 1559, 27925.
2020-07-01 05:21:17.120 CEST [25802] postgres@DBname ERROR:  canceling statement due to conflict with recovery
2020-07-01 05:21:17.120 CEST [25802] postgres@DBname DETAIL:  User was holding a relation lock for too long.
2020-07-01 05:21:17.120 CEST [25802] postgres@DBname STATEMENT:  COPY public.tablename(id, col1,col2,col3, geom) TO stdout;
2020-07-01 05:21:17.127 CEST [27925] postgres@DBname LOG:  process 27925 acquired AccessShareLock on relation 2610 of database 17948 after 10560.447 ms

关系 2610 是 pg_index。我尝试锁定此表并重现该表，但没有收到任何错误。

有人遇到过这个问题吗？感谢任何提示/修复。

Answer 1

有人以ACCESS EXCLUSIVE 模式锁定主服务器上的表。

这种锁被VACUUM (FULL)、TRUNCATE、ALTER TABLE 和类似的命令使用，但也可以在常规的VACUUM 期间发生，如果它决定在表末尾截断空页时完毕。 虽然很容易避免前面的语句，但 autovacuum 无法避免，但从 v12 开始，您可以将表上的 vacuum_truncate 存储选项设置为 off 以避免它。

无论如何，ACCESS EXCLUSIVE 锁被复制到备用服务器，在那里它与pg_dump 在表上的ACCESS SHARE 锁冲突（读取它）。

这会导致冲突。我猜max_standby_streaming_delay 设置为 10 秒，所以在延迟复制锁 10 秒后，启动过程终止查询，因此pg_dump。

要么在主服务器上不使用ACCESS EXCLUSIVE 锁，要么将max_standby_streaming_delay 设置为更高的值。