Type: | bool |
Default: | off |
Context: | sighup |
Restart: | false |
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.
This setting does not override the behavior of old_snapshot_threshold on the primary; a snapshot on the standby which exceeds the primary's age threshold can become invalid, resulting in cancellation of transactions on the standby. This is because old_snapshot_threshold is intended to provide an absolute limit on the time which dead rows can contribute to bloat, which would otherwise be violated because of the configuration of a standby.
Recommendations
On StackOverflow
- Are there any performance effects on master when using postgres streaming replication with hot_standby_feedback on
- How can I fix PostgreSQL canceling statement error on Google SQL?
- Manage conflicts and lag on Postgres Replication in Hot Standby with read heavy Slave
- terminating connection due to conflict with recovery, user was holding a relation lock for too long
- Setting hot standby feedback for a specific query in PostgreSQL
On pgsql-hackers
- Re: SELECT Query taking 200 ms on PostgreSQL compared to 4 ms on Oracle after migration.
- Re: Minimal logical decoding on standbys
- Re: Postgres is not able to handle more than 4k tables!?
- [PATCH] Full support for index LP_DEAD hint bits on standby
- Re: Add Information during standby recovery conflicts