hot_standby_feedback

Definition PG 18 manual

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.

How it works

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.

Operational considerations

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.

Workload guidance

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.