Type: | integer |
Défaut: | 30000 (30s) |
Min: | -1 (-1) |
Max: | 2147483647 (2147483647ms) |
Unité: | milliseconds (ms) |
Contexte: | sighup |
Redémarrer: | false |
Quand Hot Standby est activé, ce paramètre détermine le délai maximum d'attente que le serveur esclave doit observer avant d'annuler les requêtes en lecture qui entreraient en conflit avec les enregistrements de transactions à appliquer, comme c'est décrit dans hot-standby-conflict. max_standby_streaming_delay
est utilisé quand les données des journaux de données sont reçues via la connexion de la réplication en flux. Si cette valeur est indiquée sans unité, elle est comprise comme un nombre de millisecondes. La valeur par défaut est de 30 secondes. L'unité est la milliseconde si cette dernière n'est pas spécifiée. Une valeur de -1 autorise le serveur en attente à attendre indéfiniment la fin d'exécution des requêtes en conflit. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.
Notez que max_standby_streaming_delay
ne correspond pas au temps d'exécution maximum d'une requête avant son annulation ; il s'agit plutôt du temps maximum autorisé pour enregistrer les données d'un journal de transactions une fois qu'elles ont été récupérées du serveur maître. Donc, si une requête a occasionné un délai significatif au début du traitement d'un journal de transactions, les requêtes suivantes auront un délai beaucoup moins important.
Recommandations [EN]
Sur StackOverflow
- Manage conflicts and lag on Postgres Replication in Hot Standby with read heavy Slave
- AWS RDS PostgreSQL: what's the promised value for PostgreSQL replication lag?
- Postgres Hot Standby and Long Running Queries On Slave
- How to force Laravel database layer to retry queries that have canceled because of replication error
- How to modify the max_standby_archive_delay parameter on AWS RDS instance?