Type: | integer |
Défaut: | 60000 (1min) |
Min: | 0 (0ms) |
Max: | 2147483647 (2147483647ms) |
Unité: | milliseconds (ms) |
Contexte: | user |
Redémarrer: | false |
Depuis: | 9.3 |
Termine les connexions de réplication qui sont inactives pour plus longtemps que cette durée. Ceci est utile pour que le serveur d'envoi détecte le crash d'un standby ou une perte réseau. Si cette valeur est spécifiée sans unité, elle est comprise comme un nombre de millisecondes. La valeur par défaut est de 60 secondes. À zéro, le mécanisme est désactivé.
Avec un cluster distribué sur plusieurs lieux géographiques, utiliser plusieurs valeurs par lieu fournit plus de flexibilité dans la gestion du cluster. Une valeur plus petite est utile pour une détection plus rapide des problèmes avec un standby ayant un réseau à basse latence. Une valeur plus haute aide à mieux juger la santé d'un standby si ce dernier est situé sur un lieu distant, avec une connexion réseau à haute latence.
Sur 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?
Sur 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