在 PostgreSQL 的热备环境里，备库上的长查询可能因为主库清理旧版本行而被取消。hot_standby_feedback 提供了一种直接的取舍：让备库向主库反馈自己的事务快照，主库因此延后部分清理操作，减少备库上的查询取消；代价是主库可能积累更多死元组，表和索引膨胀也可能更严重。
这个参数容易被理解成“开启后备库查询就不会被打断”。实际边界更窄：它主要避免由 VACUUM 清理旧行版本引起的 cleanup conflict，并不能解决锁冲突、表删除或其他 DDL 相关冲突。
它解决的到底是什么
PostgreSQL 使用 MVCC 保存不同事务看到的数据版本。当主库上的 VACUUM 发现某个旧行版本已经不再被主库事务需要时，可能会清理它。但如果备库上仍有一个查询需要读取这个旧版本，备库重放主库的清理记录时就会遇到恢复冲突。
在没有反馈机制时，备库通常只能在等待和取消查询之间做选择。等待过久会影响 WAL 重放，取消查询则会让报表、检索或分析任务失败。
开启 hot_standby_feedback 后，备库会把仍在使用的事务快照反馈给主库。主库会据此推迟某些旧行版本的清理，让备库有机会完成查询。这不是免费获得的容错能力，而是把压力转移到了主库：
- 备库长查询越多，主库旧版本可能保留越久。
- 主库表和索引可能出现更多膨胀。
VACUUM可能难以回收空间，自动清理效果变差。- 主库磁盘增长和维护窗口需要重新评估。
不要把它当成所有冲突的开关
hot_standby_feedback 只覆盖一类重要冲突：备库查询需要的行版本被主库清理动作影响，也就是常说的 cleanup conflict。
它不能阻止以下情况：
- 备库查询与主库 WAL 重放中的锁操作发生冲突。
- 主库执行
DROP TABLE、ALTER TABLE等操作，备库必须重放对应变更。 - 其他会阻塞恢复的 DDL 或锁相关操作。
- 查询本身超过了备库侧的恢复等待限制。
因此，看到备库仍然出现 canceling statement due to conflict with recovery，不能直接断定参数没有生效。需要结合日志中的冲突类型、查询持续时间、备库延迟和主库膨胀情况判断。
一个可执行的配置与验证流程
下面的示例假设 PostgreSQL 服务已经运行，并且当前会话拥有修改系统参数所需的权限。生产环境请先在测试备库验证重启或 reload 行为，再决定是否持久化配置。
查看当前值：
SHOW hot_standby_feedback;
SHOW max_standby_streaming_delay;
SHOW max_standby_archive_delay;
在备库上启用反馈：
ALTER SYSTEM SET hot_standby_feedback = 'on';
然后按本实例的配置方式重新加载配置，并确认新值：
SELECT pg_reload_conf();
SHOW hot_standby_feedback;
可以用下面的 SQL 在主库观察长时间未结束的事务。长事务是造成旧版本无法及时清理的重要信号之一：
SELECT
pid,
usename,
application_name,
client_addr,
now() - xact_start AS transaction_age,
now() - query_start AS query_age,
state,
wait_event_type,
wait_event,
left(query, 120) AS query_text
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;
备库侧可以观察恢复状态和延迟：
SELECT
pg_is_in_recovery() AS is_standby,
pg_last_wal_receive_lsn() AS receive_lsn,
pg_last_wal_replay_lsn() AS replay_lsn,
now() - pg_last_xact_replay_timestamp() AS replay_delay;
如果想做一个最小化的验证实验，可以在备库启动一个较长查询，同时观察主库的 pg_stat_activity、表膨胀指标和备库日志。不要只看“查询是否还会取消”这一项，因为短期稳定可能换来长期磁盘增长。
运维上应该怎样取舍
这个参数适合读密集型备库，尤其是备库承载报表或分析查询、查询取消代价高于一定程度的主库膨胀时。但它不适合被无条件地部署到所有备库。
采用前可以建立几项监控：
- 备库查询取消次数，以及冲突类型。
- 主库表和索引膨胀趋势。
- 主库磁盘使用率和
VACUUM持续时间。 - WAL 接收、重放延迟和复制槽堆积情况。
- 长事务、空闲事务和异常长查询。
如果只是希望报表查询尽量不被取消，也可以同时从工作负载侧治理：限制查询时间、避免长时间保持事务、把重型分析迁移到专用副本，或者调整备库允许恢复等待的相关参数。不同手段影响的是不同对象，不能用一个 GUC 替代完整的查询治理。
上线前检查清单
- 确认参数设置在备库，而不是误改主库。
- 记录开启前的冲突次数、复制延迟和磁盘增长率。
- 验证备库查询取消是否确实属于 cleanup conflict。
- 为主库表膨胀和磁盘使用设置告警。
- 为长事务、长查询和空闲事务设置治理规则。
- 明确锁冲突、
DROP冲突仍然可能取消备库查询。
hot_standby_feedback 的价值在于重新分配风险，而不是消除风险。把它看成“用主库空间和清理效率换备库查询稳定性”的开关，才能在复制延迟、查询体验和存储成本之间做出可观测、可回滚的决定。