Si positionné à on, toute erreur terminera la session courante. Par défaut, ce paramètre est à off, pour que seules des erreurs de niveau FATAL puissent terminer la session.

Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Quand ce paramètre est configuré à on, ce qui est sa valeur par défaut, PostgreSQL redémarrera automatiquement après un arrêt brutal d'un processus serveur. Il est généralement préférable de laisser cette valeur à on car cela maximise la disponibilité de la base de données. Néanmoins, dans certaines circonstances, comme le fait que PostgreSQL soit lancé par un outil de clustering, il pourrait être utile de désactiver le redémarrage pour que l'outil puisse avoir le contrôle et prendre toute action qui lui semble approprié.

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 nouveau 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.

Quand configuré à fsync, qui est la valeur par défaut, PostgreSQL va ouvrir récursivement et synchroniser tous les fichiers du répertoire data avant de commencer la récupération après un crash. Les fichiers accessibles par des liens symboliques dans le répertoire des journaux de transactions et dans les tablespaces sont également concernés, mais pas les autres liens symboliques. Cette opération permet de s'assurer que tous les journaux de transactions et fichiers de données sont stockés de manière durable sur disque avant de rejouer les changements. Ce comportement s'applique dès que le serveur n'a pas été arrêté proprement, ce qui inclue les copies faites avec pg_basebackup.

Sous Linux, syncfs peut être utilisé en lieu et place de fsync pour demander au système d'exploitation de synchroniser les systèmes de fichiers qui contiennent le répertoire des données, des journaux de transactions et de chaque tablespace (mais pas d'autres systèmes de fichiers accessibles par des liens symboliques). Il est possible que cela soit beaucoup plus rapide que l'utilisation du paramètre fsync, car il n'est pas nécessaire d'ouvrir chaque fichier un par un. D'un autre côté, ce paramétrage pourra aussi être plus lent si le système de fichiers est partagé avec d'autres applications qui modifient beaucoup de fichiers, étant donné que ces fichiers seront aussi écrits sur le disque. De plus, sur les versions de Linux inférieure à la 5.8, les erreurs d'entrée/sortie rencontrées lors de l'écriture des données sur le disque peuvent ne pas être remontées à PostgreSQL et les messages d'erreurs correspondants pourraient n'apparaître que dans les fichiers de trace du noyau.