# hot_standby_feedback

> hot_standby_feedback：允许热备库向主库反馈信息，以避免查询冲突。实测在档范围为 PG9.1–19 Beta 3；最后在档的 PG19 Beta 3 启动默认值为 off，context 为 sighup。这是测试版快照事实，PostgreSQL 19 正式发布前仍可能变化。
---

> [!NOTE]
> **Fact — 官方简述译文**：允许热备库向主库反馈信息，以避免查询冲突。

## 身份 {#identity}

| 字段 | 值 | 含义 |
| --- | --- | --- |
| 类型 | `bool` | 上游 pg_settings 类型 |
| Context | `sighup` | 配置 reload 后生效 |
| 单位 | — | 原始单位 |
| 范围 | — | 最后在档版本的原始上下限 |
| 枚举值 | — | 非枚举类型记为 — |
| 分类 | Replication / Standby Servers | 上游分类 |
| 最后 boot 值 | `off` | off |
{.fields meta="-"}

## 生命周期 {#lifecycle}

| Fact | 值 |
| --- | --- |
| 首次观测 | PG9.1 |
| 在档版本 | PG9.1–19 Beta 3 |
| 移除版本 | 否 |
| 引入提交 | [`bca8b7f16a3e`](https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=bca8b7f16a3e720794cb0afbdb3733be4f8d9c2c) — Hot Standby feedback for avoidance of cleanup conflicts on standby. Standby optionally sends back information about oldestXmin of queries which is then checked and applied to the WALSender's proc->xmin. GetOldestXmin() is modified slightly to agree with GetSnapshotData(), so that all backends on primary include WALSender within their snapshots. Note this does nothing to change the snapshot xmin on either master or standby. Feedback piggybacks on the standby reply message. vacuum_defer_cleanup_age is no longer used on standby, though parameter still exists on primary, since some use cases still exist. |
| 提交日期 | 2011-02-16 |
| Discussion | — |

## 默认值变迁 {#default-history}

| 版本 | 原始 `boot_val` | 单位 | 人类可读值 |
| --- | --- | --- | --- |
| PG9.1–19 Beta 3 | `off` | — | off |
{.full-width caption="PG9.0–19 Beta 3 实测 boot 默认值"}

## 机制详解 {#mechanism}

启用后，备库会向主库或上游备库报告当前查询快照仍需要的可见性信息，使上游避免清理由这些查询仍可见的旧行版本。反馈发送频率不会高于 wal_receiver_status_interval。

避免清理冲突会把代价转移到主库：死亡行版本存活更久，表与索引膨胀以及后续 VACUUM 工作都会增加。在级联复制中反馈会继续向上传递，因此很下游的一个旧快照也可能影响主库。

该机制只缓解清理记录冲突，并不能消除全部热备冲突。DDL 锁、删除对象、表空间操作和某些页面级冲突仍会取消查询。无槽备库断开时反馈会中断，时钟跳变也可能影响发送时序。

## 调优建议 {#tuning-advice}

> [!TIP]
> **Advice。** 以下建议是工作负载起点，必须用真实测量验证。

| 场景 | 建议 |
| --- | --- |
| OLTP | 只有减少备库查询取消的收益高于主库膨胀风险时才启用。限制备库查询时长，监控事务年龄、死亡元组、表增长、VACUUM 进度和 pg_stat_database_conflicts；纯 HA 备库通常更重视及时重放。 |
| OLAP | 对长查询报表备库很有价值，但必须搭配工作负载超时和主库膨胀预算。如果分析快照经常阻止清理数小时，应考虑独立报表拓扑。 |
| 小规格 | 除非已证明查询取消是问题，否则从 off 开始。有限存储使主库膨胀风险更高；启用后应使用较短查询上限和积极监控。 |
{.full-width}

## Pigsty 取值 {#pigsty}

以下值来自固定 8 核、32 GiB、100 GiB SSD 夹具，并按 PG19 Beta 3 渲染当前 Pigsty 模板；这不表示 Pigsty 当前支持该历史或测试版本。

| 模板 | 有效值 | 与上游 boot 比较 | 源表达式 |
| --- | --- | --- | --- |
| OLTP | `on` | 不同于 boot 值 | `'on'` |
| OLAP | `on` | 不同于 boot 值 | `'on'` |
| CRIT | `on` | 不同于 boot 值 | `'on'` |
| TINY | `on` | 不同于 boot 值 | `'on'` |
{.full-width}

> [!CAUTION]
> **Advice — 待人工复核。** 当前 Pigsty 模板投影事实：OLTP: PG9.1–19 Beta 3 = on (dcs)；OLAP: PG9.1–19 Beta 3 = on (dcs)；CRIT: PG9.1–19 Beta 3 = on (dcs)；TINY: PG9.1–19 Beta 3 = on (dcs)。 建议（待人工复核）——发布前应结合当前 Pigsty 模板及其实际支持的 PostgreSQL 版本确认运维意图。

## 常见坑 {#common-pitfalls}

- 启用后忽略主库表或索引膨胀。
- 期待它阻止 DDL、锁、删除数据库或表空间冲突。
- 允许下游备库无限长查询长期阻止上游清理。
- 认为无槽备库断开期间反馈仍然有效。
- 分析反馈时序时忽略时钟跳变和 wal_receiver_status_interval。

## 关联参数 {#related-parameters}

[`max_standby_streaming_delay`](/zh/parameters/max-standby-streaming-delay/) · [`max_standby_archive_delay`](/zh/parameters/max-standby-archive-delay/) · [`wal_receiver_status_interval`](/zh/parameters/wal-receiver-status-interval/) · [`primary_slot_name`](/zh/parameters/primary-slot-name/) · [`autovacuum_vacuum_scale_factor`](/zh/parameters/autovacuum-vacuum-scale-factor/) · [`log_recovery_conflict_waits`](/zh/parameters/log-recovery-conflict-waits/)

## 参考资料 {#references}

- [PostgreSQL 19 Beta 3 — hot_standby_feedback](https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-HOT-STANDBY-FEEDBACK)
- [PostgreSQL 18：处理热备查询冲突](https://www.postgresql.org/docs/18/hot-standby.html#HOT-STANDBY-CONFLICT)
- [PostgreSQL 18：复制槽](https://www.postgresql.org/docs/18/warm-standby.html#STREAMING-REPLICATION-SLOTS)
- [PostgreSQL 19 发行说明](https://www.postgresql.org/docs/19/release-19.html)
- [机器可读 GUC 全量导出](/data/guc.jsonl)