由于与ubuntu上postgresql中的恢复冲突，pg_dump在备用服务器上取消语句失败
由于与ubuntu上postgresql中的恢复冲突，pg_dump在备用服务器上取消语句失败
提问于 2020-07-01 21:44:29
在我的生产服务器上，备份有时会失败，并显示以下消息。此备份计划在备用节点上进行。(在我的环境中配置了流复制。)在此备份时间内没有任何进程在运行。这是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。我试图锁定该表并重现该表，但没有得到任何错误。
有人遇到过这个问题吗？任何提示/修复都是值得感谢的。
回答 1
Stack Overflow用户
发布于 2020-07-01 22:00:54
有人在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设置为更高的值。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/62678279
复制相关文章
相似问题
腾讯云开发者
