| Type: | integer |
| Default: | 60000 (1min) |
| Min: | 0 (0ms) |
| Max: | 2147483647 (2147483647ms) |
| Unit: | milliseconds (ms) |
| Context: | user |
| Restart: | false |
| Since: | 9.3 |
Terminate replication connections that are inactive for longer than this amount of time. This is useful for the sending server to detect a standby crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism.
With a cluster distributed across multiple geographic locations, using different values per location brings more flexibility in the cluster management. A smaller value is useful for faster failure detection with a standby having a low-latency network connection, and a larger value helps in judging better the health of a standby if located on a remote location, with a high-latency network connection.
On StackOverflow
- PostgreSQL logical replication stacks with error 'could not receive data from WAL stream: server closed the connection unexpectedly'
- how to resolve ERROR: could not start WAL streaming: ERROR: replication slot "xxx" is active for PID 124563
- Getting Exception : "replication slot "XXX" is active for PID XXX`" on deploying service on kubernetes with RollingUpdate deployment strategy
- postgresql 9.4 streaming replication
- What causes data on a read-replica to be an old_snapshot and cause conflict?
On pgsql-hackers
- outdated references to replication timeout
- RE: Add client connection check during the execution of the query
- Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)
- Recent eelpout failures on 9.x branches
- Re: Logical Replication - behavior of ALTER PUBLICATION .. DROP TABLE and ALTER SUBSCRIPTION .. REFRESH PUBLICATION