| Type: | integer |
| Défaut: | 0 (0ms) |
| Min: | 0 (0ms) |
| Max: | 2147483647 (2147483647ms) |
| Unité: | milliseconds (ms) |
| Contexte: | sighup |
| Redémarrer: | false |
| Depuis: | 12 |
Par défaut, un serveur standby restaure les enregistrements des WAL du serveur d'envoi dès que possible. Il peut être utile d'avoir une copie qui appliquer les données de réplication avec un délai spécifié pour prévenir en cas de perte de données. Ce paramètre vous permet de repousser l'application de la restauration sur une période de temps fixée. Par exemple, si vous configurez ce paramètre à 5min, le standby ne rejouera chaque validation de transaction seulement quand l'heure système sur le standby est au moins cinq minutes après l'heure de validation rapportée par le primaire. Si cette valeur est spécifiée sans unité, elle est comprise comme un nombre de millisecondes. La valeur par défaut est zéro, pour ne pas ajouter de délai.
Il est possible que le délai de réplication entre les serveurs dépasse la valeur de ce paramètre, auquel cas aucun délai n'est ajouté. Notez que le délai est calculé entre l'horodatage du WAL écrit sur le primaire et l'heure système actuel sur le secondaire. Les délais dans le transfert, à cause d'un retard réseau ou de configuration de réplication en cascade, pourraient réduire le temps d'attente de façon importante. Si les horloges systèmes du primaire et du secondaire ne sont pas synchronisées, ceci pourrait amener la restauration à appliquer des enregistrements plus rapidement que souhaité. Ceci n'est pas un problème important parce que la configuration intéressante de ce paramètre est bien plus importante que les déviations habituelles d'horloge entre serveurs.
Le délai n'est appliqué que sur les enregistrements WAL des validations de transaction. Les autres enregistrements sont rejoués aussi rapidement que possible, ce qui n'est pas un problème vu que les règles de visibilité avec MVCC nous assurent que les effets ne sont pas visibles tant que l'enregistrement de validation correspondant n'est pas appliqué.
Le délai survient une fois que la base de données en restauration a atteint un point de cohérence, et jusqu'à ce que le standby soit promu. Après cela, le standby arrêtera toute restauration et sans délai.
Ce paramètre vise les déploiements de réplication par flux. Néanmoins, la configuration de ce paramètre sera honorée dans tous les cas, sauf dans le cas de la restauration après un crash. hot_standby_feedback se verra imposé le délai, ce qui peut amener de la fragmentation sur le serveur primaire. N'activez les deux qu'avec précaution.
La réplication synchrone est affectée par ce paramétrage quand synchronous_commit est configuré à remote_apply ; chaque COMMIT aura besoin d'attendre son application.
Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.