PostgreSQL中两种恢复冲突报错触发场景的技术咨询

我来帮你理清楚这两种恢复冲突报错的触发逻辑，刚好之前在维护PostgreSQL备库查询集群时踩过这个坑：

首先得明确核心前提：这两种报错都发生在备库（流复制或归档恢复模式下），本质是备库上的查询/事务和主库同步过来的WAL日志操作产生了冲突，PG需要在“维持备库查询可用性”和“保证备库与主库数据一致性”之间做取舍。

一、触发Cancelling Statement due to conflict with recovery的场景 #

这是PG的「温和处理」方式，优先只终止冲突的单个语句，保留整个连接：

• 当备库上正在运行的单个查询语句和主库同步的写入/更新/删除操作冲突时触发。比如你在备库跑了一个长时查询，主库刚好修改了这个查询正在扫描的行，备库要应用这条WAL日志就会和查询产生冲突。
• 这个行为和备库的max_standby_streaming_delay（流复制场景）或max_standby_archive_delay（归档恢复场景）配置直接相关：如果冲突语句的运行时长还没超过这个阈值，PG会先发送取消信号干掉冲突语句，而不是断连接。
• 这种情况对应用户侧的影响很小，因为只是单个语句失败，连接还能正常复用，所以你说你的代码能优雅处理这种错误完全合理。

二、触发terminating connection due to conflict with recovery的场景 #

这是PG的「强硬处理」方式，只有当温和处理失效或冲突严重威胁恢复进度时才会触发：

• 冲突语句无法响应取消信号：比如查询卡在了不可中断的操作里（比如某些系统级函数调用、长时间的磁盘IO等待），PG尝试取消语句失败后，就会直接断开整个连接。
• 冲突的是整个长事务快照：如果你在备库开了一个长时间未提交的事务，一直持有旧快照，主库的大量修改操作持续和这个快照冲突，超过配置的延迟阈值后，PG会直接终止这个事务所在的连接——因为这个长快照已经严重阻碍了备库的WAL应用和旧数据清理。
• 备库恢复进度受到严重影响：当备库因为某个连接的查询/事务，导致WAL日志堆积、恢复进度滞后太多，PG会选择终止连接来优先保证备库能跟上主库的步伐。

对你遇到的SQLAlchemy问题的补充 #

当连接被直接终止时，客户端会收到ConnectionDoesNotExistError是正常的——因为连接已经被PG主动断开了，SQLAlchemy的连接池里会残留无效的连接引用，后续的连接复用或清理操作就容易触发垃圾回收相关的错误。解决的核心思路还是尽量减少备库上的长事务、长查询，或者调整备库的恢复延迟配置来适配业务场景。

内容来源于stack exchange