PostgreSQL只读备库执行查询时，如果出现 canceling statement due to conflict with recovery，并不是数据库突然允许写入失败，而是查询需要保留的快照、锁或缓冲区与WAL重放发生了冲突。为了继续追赶主库，备库取消了查询。
这类故障必须在查询可用性、复制时效和主库清理之间做取舍。 单纯把延迟参数设得很大，会把查询取消变成复制积压，并不一定更安全。
先确认连接节点确实处于恢复状态
在发生错误的数据库节点执行：
psql -X -c "SELECT pg_is_in_recovery();"
psql -X -c "SHOW hot_standby;"
psql -X -c "SHOW max_standby_streaming_delay;"
psql -X -c "SHOW max_standby_archive_delay;"
psql -X -c "SHOW hot_standby_feedback;"pg_is_in_recovery() 返回true说明这是备库。max_standby_streaming_delay 控制流复制WAL重放愿意等待冲突查询的总延迟，max_standby_archive_delay 对从归档读取的WAL生效；这两个参数应设置在备库，不是在主库。
延迟值不是每条查询独享的完整执行时间。 PostgreSQL按接收WAL后的累计应用延迟判断，备库已经落后时，下一条冲突查询可能很快被取消。
用统计视图区分冲突类型
PostgreSQL在备库提供 pg_stat_database_conflicts，按数据库统计恢复冲突导致的查询取消：
psql -X -c "SELECT datname,confl_tablespace,confl_lock,confl_snapshot,confl_bufferpin,confl_deadlock FROM pg_stat_database_conflicts ORDER BY datname;"记录两次采样的差值，才能判断当前增长的冲突类型。confl_snapshot 常与主库清理旧行版本有关；confl_lock 表示WAL重放等待备库查询持有的锁；confl_bufferpin 则与查询长时间固定缓冲区页面有关。
同时检查备库日志中的完整DETAIL与CONTEXT，并观察长查询：
psql -X -c "SELECT pid,now()-query_start AS runtime,state,wait_event_type,wait_event,left(query,120) FROM pg_stat_activity WHERE backend_type='client backend' ORDER BY query_start;"不要只根据错误主句调整参数，DETAIL和冲突计数才决定正确方向。
为什么VACUUM会影响只读查询
主库上的更新和删除会产生旧行版本，VACUUM在安全时清理它们。但主库无法直接知道备库上某个长查询仍需要哪些旧版本；相关清理记录进入WAL后，备库重放可能与该查询快照冲突。
官方文档指出，即使表没有需要清理的已删除行，VACUUM更新可见性映射时也可能与备库的索引仅扫描产生冲突。频繁更新的表尤其容易让长时间报表查询被取消。
因此，不应通过停用主库autovacuum来保护只读查询。关闭清理会增加表和索引膨胀、事务ID风险与维护压力，代价通常更高。
三种处理方向及风险边界
第一种是缩短或拆分备库查询，避免长事务和长时间游标；对报表按时间或主键分段，并为非关键查询设置合理的 statement_timeout。这是对高可用备库影响最小的做法。
第二种是在备库适度提高 max_standby_streaming_delay 或 max_standby_archive_delay，让WAL重放多等一会。设置为 -1 会允许无限等待，可能让备库长期落后，不适合作为默认的高可用配置。
第三种是在备库启用 hot_standby_feedback，让主库知道备库仍需要的快照，减少早期清理冲突。但它会延迟主库清理死行，可能造成表膨胀；而且它不能消除所有锁、表空间或缓冲区冲突。
需要压测取舍时，可在 萤光云 创建隔离主备环境；要模拟异地复制延迟，也可以用 LightNode 部署临时节点。测试数据不应包含生产隐私信息。
受控修改参数并观察效果
确认业务优先级后，可以在备库通过配置文件或受控命令修改，例如：
psql -X -c "ALTER SYSTEM SET max_standby_streaming_delay = '60s';"
psql -X -c "SELECT pg_reload_conf();"如果决定启用反馈：
psql -X -c "ALTER SYSTEM SET hot_standby_feedback = on;"
psql -X -c "SELECT pg_reload_conf();"执行者需要相应管理权限。托管PostgreSQL可能要求使用参数组或控制台，并可能限制可修改项。修改后必须同时监控查询取消数、WAL重放延迟和主库表膨胀，不能只观察客户端错误是否减少。
每次只改变一个主要变量并保留回退值。 如果备库承担灾备优先任务，应选择较低延迟；专用报表副本才适合为查询容忍更高复制延迟。
验收查询和复制都处于可接受范围
在备库记录冲突计数、接收与重放位置以及重放时间：
psql -X -c "SELECT now()-pg_last_xact_replay_timestamp() AS replay_time_lag,pg_wal_lsn_diff(pg_last_wal_receive_lsn(),pg_last_wal_replay_lsn()) AS pending_bytes;"
psql -X -c "SELECT * FROM pg_stat_database_conflicts;"pg_last_xact_replay_timestamp() 在没有最近事务时可能返回NULL或让时间差缺乏代表性，因此还要结合LSN差值、主库写入活动和监控系统判断。对启用 hot_standby_feedback 的方案，应同时观察主库死元组与autovacuum状态。
验收通过应满足关键查询在目标时限内完成、冲突取消率降至可接受范围、备库延迟不超过恢复目标，并且主库没有持续恶化的膨胀趋势。
FAQ
只读查询为什么会阻塞复制？
查询虽然不写数据，却依赖一致性快照、锁和缓冲区；WAL重放要应用主库的删除、DDL或清理变化时可能与这些资源冲突。
把max_standby_streaming_delay设为-1最省事吗？
不是。它可能让WAL无限等待冲突查询，造成备库严重落后，降低故障切换时的数据时效。
hot_standby_feedback开启后还会有冲突吗？
会。它主要减少旧快照清理冲突，不能消除所有恢复冲突，而且可能增加主库表膨胀。
温馨提示
只读库查询冲突没有脱离业务目标的万能参数。先确认备库职责和冲突类型，再在查询时长、复制延迟与主库清理之间设置可量化边界，并持续监控三者。
