Parameter · Replication / Standby Servers
hot_standby_feedback
Allows feedback from a hot standby to the primary that will avoid query conflicts.
- Default:
off - Type: bool
- Applies: Reload
In plain words
VACUUM on the primary removes old row versions nobody there needs. But a long query on a standby may still need them, and when the cleanup arrives in the WAL, that query gets cancelled. With hot_standby_feedback = on, the standby regularly reports its oldest snapshot to the primary, and VACUUM keeps those rows.
The trade-off: long standby queries now cause bloat on the primary.
For DBAs and operators
The WAL receiver sends the standby's xmin (and catalog_xmin of any logical slots) with its status messages, at most every wal_receiver_status_interval. The primary treats it like an open snapshot. Visible as backend_xmin in pg_stat_replication, or as xmin in pg_replication_slots when a slot is used.
With a physical slot, the xmin persists even while the standby is disconnected, so a dead standby can block vacuum on the primary indefinitely. Without a slot, feedback stops at disconnect and a reconnecting standby may see conflicts.
It removes snapshot conflicts ("User query might have needed to see row versions that must be removed") but not all of them: lock conflicts (e.g. vacuum truncating a table, DROP TABLE), dropped tablespaces/databases and buffer-pin conflicts can still cancel queries. Required for sync_replication_slots.
-- on the primary: how old is each standby's horizon?
SELECT application_name, backend_xmin, age(backend_xmin)
FROM pg_stat_replication;How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Hot standby and recovery conflicts VACUUM WAL receiver Snapshots and visibility Startup process MVCC: row versions Replication slots
Related parameters
max_standby_streaming_delay hot_standby wal_receiver_status_interval primary_slot_name sync_replication_slots