Type: | bool |
Défaut: | off |
Contexte: | postmaster |
Redémarrer: | true |
Depuis: | 9.4 |
Lorsqu'il est configuré à off, ce qui est la valeur par défaut, PostgreSQL lèvera une erreur de niveau PANIC en cas d'échec de synchronisation des fichiers de données modifiés sur le système de fichiers. Ceci causera le crash du serveur de bases de données. Ce paramètre peut seulement être configuré au lancement du serveur.
Sur certains systèmes d'exploitation, le statut des données dans le cache disque du noyau n'est pas connu après un échec de synrhconisation. Dans certains cas, ce statut peut être entièrement oublié, rendant risquée toute nouvelle tentative. La deuxième tentative pourrait être rapportée comme réussi alors qu'en fait la donnée a été perdue. Dans ces circonstances, la seule façon d'éviter une perte de données est de rejouer les journaux de transactions après chaque statut d'échec, de préférence après une investigation sur la cause originale de l'échec et de remplacer tout matériel défectueux.
S'il est configuré à on, PostgreSQL renverra une erreur mais continuera à s'exécuter pour que l'opération de synchronisation sur disque soit tentée de noueau au prochain checkpoint. Il faut le configurer à on après avoir investigué sur le traitement par le système d'exploitation des données en cache dans le cas d'un échec de synchronisation.
Sur StackOverflow
- Geoserver WFS + PostgreSQL with large table impossibly slow
- Why does "explain analyzing" this query fnish fast (showing a parallel plan), while running the actual query without "explain analyze" doesn't?
- PostgreSQL 13 sometimes works but sometimes huge execution time
- Postgresql sequential scan slow performance on 500 million rows
- How to log every query in Postgresql