hot_standby_feedback开启后主库wal不清理的典型现象是wal堆积、pg_wal目录膨胀、backend_xmin长期停滞且远小于txid_current()，根源在于备库长事务阻塞主库vacuum和wal回收。
hot_standby_feedback 导致主库 WAL 不清理的典型现象
开启 hot_standby_feedback = on 后，主库 WAL 日志堆积、pg_wal/ 目录持续膨胀，甚至触发磁盘告警——这不是 bug，而是机制使然。备库通过该参数向主库反馈“我还在用哪些事务快照”，主库因此不敢回收那些仍被备库需要的旧 WAL 和元组（tuple），导致 vacuum 无法清理死元组，表体积只增不减。
- 常见错误现象：
pg_stat_replication中backend_xmin长期停滞不前，且明显小于主库当前txid_current() - 使用场景：仅在备库执行长事务（如报表查询、逻辑解码消费慢、未提交的
BEGIN; SELECT ...;）时风险最高 - 性能影响：WAL 归档压力增大；
pg_xact/和pg_subtrans/文件也可能膨胀；主库VACUUM效率下降，bloat 加剧
如何快速定位是 hot_standby_feedback 引发的膨胀
别猜，直接查备库反馈的 xmin 和主库实际 xmin 差距。这是最直接的证据链。
- 在备库执行：
SELECT backend_xmin FROM pg_stat_replication WHERE application_name = 'your_standby_name'; - 在主库执行：
SELECT txid_current(), age(txid_current(), backend_xmin) AS xmin_age FROM pg_stat_replication WHERE application_name = 'your_standby_name'; - 如果
xmin_age持续大于 100 万（或远超业务事务速率），基本可确认是备库长事务拖住了主库清理 - 注意：该值不是延迟秒数，而是已分配的事务 ID 数量差，单位是 txid，不是时间
缓解策略优先级与实操建议
关闭 hot_standby_feedback 最快，但可能引发查询取消；更稳妥的是控制源头——让备库别卡住 xmin。
- 首选：在备库侧限制长查询，设置
idle_in_transaction_session_timeout = 60000（单位毫秒），避免空闲事务长期持有 snapshot - 次选：若必须开
hot_standby_feedback，主库配合调大max_replication_slots和监控pg_replication_slots，防止 slot 卡住 WAL 清理 - 慎用：关掉
hot_standby_feedback后，备库遇到冲突会报错canceling statement due to conflict with recovery，需业务容忍重试 - 不能依赖：单纯调大
vacuum_defer_cleanup_age只会掩盖问题，恶化 bloat
监控项必须加到告警清单里
靠人工查太晚。这几个指标不进 Prometheus + Alertmanager，等于没防住。
-
pg_stat_replication.backend_xmin与主库txid_current()的差值（建议阈值：> 500000） -
pg_replication_slots.active = false且pg_replication_slots.restart_lsn长期不推进（slot 死锁信号） -
pg_wal目录大小周环比增长 > 40%，同时checkpoints_timed频次下降（说明 WAL 积压抑制了 checkpoint） - 备库
pg_stat_activity.state = 'idle in transaction'且backend_start超过 5 分钟的会话数 > 2
