{"Entry":{"collection":"guc","key":"hot_standby_feedback","name":"hot_standby_feedback","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Replication / Standby Servers","category_zh":"","changed_in":[],"changes":[{"documentation_changed":false,"fields":{},"from":"9.0","status":"added","to":"9.1"},{"documentation_changed":true,"fields":{},"from":"9.1","status":"changed","to":"9.2"},{"documentation_changed":true,"fields":{},"from":"9.5","status":"changed","to":"9.6"},{"documentation_changed":true,"fields":{},"from":"16","status":"changed","to":"17"},{"documentation_changed":true,"fields":{},"from":"17","status":"changed","to":"18"}],"content_hash":"bda92403a5804e4799a59c0c3a2f7b59850e96fb72beaf3177384f42b149922d","context":"","default_changed_in":[],"default_history":[{"from":"9.1","to":"19","value":"off"}],"editorial":{"advice":{"olap":"It is useful for reporting standbys with long reads, but pair it with workload timeouts and a bloat budget on the primary. Consider a dedicated reporting topology if analytical snapshots routinely block cleanup for hours.","oltp":"Enable it only when reducing standby query cancellation is worth possible primary bloat. Bound standby query duration, monitor transaction age, dead tuples, table growth, vacuum progress, and pg_stat_database_conflicts; an HA-only standby often benefits more from timely replay than long query survival.","small":"Start from off unless cancellations are a demonstrated problem. Limited storage makes primary bloat especially risky; if enabled, use short query limits and aggressive monitoring."},"mechanism":["A standby with feedback enabled reports information about snapshots needed by its running queries to the primary or upstream standby. The upstream can then avoid vacuum cleanup that would remove row versions still visible to those queries. Messages are not sent more frequently than wal_receiver_status_interval.","Avoiding cleanup conflicts transfers the cost to the primary: dead row versions can remain longer, increasing table and index bloat and vacuum work. In cascading replication feedback is passed upstream, so one old snapshot far downstream can affect the primary.","The mechanism addresses cleanup-record conflicts, not every hot-standby conflict. DDL locks, dropped objects, tablespace actions, and some page-level conflicts can still cancel queries. Feedback also has gaps while a non-slot standby is disconnected, and clock changes can disturb its timing."],"pitfalls":["Enabling it and ignoring table or index bloat on the primary.","Expecting it to prevent DDL, lock, database-drop, or tablespace conflicts.","Allowing an unbounded long query on a downstream standby to hold back cleanup upstream.","Assuming feedback remains effective while a slotless standby is disconnected.","Ignoring clock jumps and wal_receiver_status_interval when reasoning about feedback timing."],"references":[{"title":"PostgreSQL 19 Beta 4: hot_standby_feedback","url":"https://www.postgresql.org/docs/19/runtime-config-replication.html#GUC-HOT-STANDBY-FEEDBACK"},{"title":"PostgreSQL 18: Handling Hot Standby Query Conflicts","url":"https://www.postgresql.org/docs/18/hot-standby.html#HOT-STANDBY-CONFLICT"},{"title":"PostgreSQL 18: Replication Slots","url":"https://www.postgresql.org/docs/18/warm-standby.html#STREAMING-REPLICATION-SLOTS"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["max_standby_streaming_delay","max_standby_archive_delay","wal_receiver_status_interval","primary_slot_name","autovacuum_vacuum_scale_factor","log_recovery_conflict_waits"],"summary":"hot_standby_feedback — Allows feedback from a hot standby to the primary that will avoid query conflicts. Observed in PG9.1–19 Beta 4; its last measured boot default is off in PG19 Beta 4, with sighup context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"9.1","group":"Replication","group_slug":"replication","imported_at":"2026-09-27T17:57:31.354261+08:00","intro_commit":{"authored_at":"2011-02-16T19:29:37Z","discussion":[],"hash":"bca8b7f16a3e720794cb0afbdb3733be4f8d9c2c","subject":"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-\u003exmin. 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.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=bca8b7f16a3e720794cb0afbdb3733be4f8d9c2c"},"key":"hot_standby_feedback","last_version":"20","max_val":"","min_val":"","name":"hot_standby_feedback","position":167,"present_in":["9.1","9.2","9.3","9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"short_desc":"Specifies whether or not a hot standby will send feedback to the primary or upstream standby about queries currently executing on the standby.","short_desc_zh":"","source_rev":"english-manuals:3fe6e376de8d685b152805f46e23170ab72b10300ffa4c42d6e7da4e8c439b30","unit":"","vartype":"bool"}},"Definition":{"Collection":"guc","Key":"hot_standby_feedback","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"hot_standby_feedback","SourceRevision":"english-manuals:3fe6e376de8d685b152805f46e23170ab72b10300ffa4c42d6e7da4e8c439b30","Facts":{"boot_val":"off","category":"Replication / Standby Servers","context":"sighup","description":"Specifies whether or not a hot standby will send feedback to the primary or upstream standby about queries currently executing on the standby. This parameter can be used to eliminate query cancels caused by cleanup records, but can cause database bloat on the primary for some workloads. Feedback messages will not be sent more frequently than once per wal_receiver_status_interval. The default value is off. This parameter can only be set in the postgresql.conf file or on the server command line. If cascaded replication is in use the feedback is passed upstream until it eventually reaches the primary. Standbys make no other use of feedback they receive other than to pass upstream. Note that if the clock on standby is moved ahead or backward, the feedback message might not be sent at the required interval. In extreme cases, this can lead to a prolonged risk of not removing dead rows on the primary for extended periods, as the feedback mechanism is based on timestamps.","doc":{"anchor":"GUC-HOT-STANDBY-FEEDBACK","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"hot_standby_feedback","short_desc":"Allows feedback from a hot standby to the primary that will avoid query conflicts.","source":"pg-settings-source-snapshot","unit":null,"vartype":"bool"},"ManualEvidence":{"doc":{"anchor":"GUC-HOT-STANDBY-FEEDBACK","file":"runtime-config-replication.html","lang":"en","sha256":"c78480a202f8579e2655e080060afe4859c9eb26a16318fb9099dabb178fb32d","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"hot_standby_feedback","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"hot_standby_feedback","Summary":"","BodyHTML":"\u003cp\u003e指定一个热备机是否将会向主库或上游备库发送有关于备库上当前正被执行的查询的反馈。这个参数可以被用来消除由清理记录引起的查询取消，但是在某些负载下可能导致主库上的数据库膨胀。反馈消息的发送频度不会高于每个\u003ccode\u003ewal_receiver_status_interval\u003c/code\u003e周期发送一次。默认值是\u003ccode\u003eoff\u003c/code\u003e。这个参数只能在\u003ccode\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。\u003c/p\u003e\u003cp\u003e如果使用级联复制，反馈将被向上游传递直到它最后到达主库。备库在接收到反馈之后除了传递给上游不会做任何其他操作。\u003c/p\u003e\u003cp\u003e请注意，如果备库上的时钟被向前或向后调整，反馈消息可能无法按要求的时间间隔发送。在极端情况下，由于该反馈机制基于时间戳，这可能导致主库长时间面临无法移除死元组的风险。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"3a50bb70d31bfd966c78d52f468041c12ac93a7079094bf003d4a500f7f233de","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e指定一个热备机是否将会向主库或上游备库发送有关于备库上当前正被执行的查询的反馈。这个参数可以被用来消除由清理记录引起的查询取消，但是在某些负载下可能导致主库上的数据库膨胀。反馈消息的发送频度不会高于每个\u003ccode class=\"varname\"\u003ewal_receiver_status_interval\u003c/code\u003e周期发送一次。默认值是\u003ccode class=\"literal\"\u003eoff\u003c/code\u003e。这个参数只能在\u003ccode class=\"filename\"\u003epostgresql.conf\u003c/code\u003e文件中或在服务器命令行上设置。\u003c/p\u003e\u003cp\u003e如果使用级联复制，反馈将被向上游传递直到它最后到达主库。备库在接收到反馈之后除了传递给上游不会做任何其他操作。\u003c/p\u003e\u003cp\u003e请注意，如果备库上的时钟被向前或向后调整，反馈消息可能无法按要求的时间间隔发送。在极端情况下，由于该反馈机制基于时间戳，这可能导致主库长时间面临无法移除死元组的风险。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}