Type: enum
Défaut: on
Contexte: user
Redémarrer: false
Valeurs: [local, remote_write, remote_apply, on, off]

Indique si la validation des transactions doit attendre l'écriture des enregistrements WAL avant que la commande ne renvoie une indication de réussite au client. Les valeurs valides sont on, remote_apply, remote_write, local et off. La configuration par défaut, et la plus sûre, est on. Quand ce paramètre est désactivé (off), il peut exister un délai entre le moment où le succès est rapporté et le moment où la transaction est vraiment protégée d'un arrêt brutal du serveur. (Le délai maximum est de trois fois wal_writer_delay.) Contrairement à fsync, la configuration de ce paramètre à off n'implique aucun risque d'incohérence dans la base de données : un arrêt brutal du système d'exploitation ou d'une base de données peut résulter en quelques transactions récentes prétendument validées perdues malgré tout. Cependant, l'état de la base de données est identique à celui obtenu si les transactions avaient été correctement annulées. C'est pourquoi la désactivation de synchronous_commit est une alternative utile quand la performance est plus importante que la sûreté de la transaction. Pour plus de discussion, voir wal-async-commit.

Si synchronous_standby_names n'est pas vide, ce paramètre contrôle aussi si les validations de transaction attendent que les enregistrements de transaction associés soient répliqués sur les serveurs standbys. Configuré à on, les validations attendront les réponses des standbys synchrones courants indiquant qu'ils ont reçu l'enregistrement de validation de la transaction et qu'ils l'ont enregistré sur disque. Ceci assure que la transaction ne sera pas perdu, sauf si le serveur primaire et tous les serveurs secondaires synchrones souffrent de corruption sur le stockage de la base de données. Si configuré à remote_apply, les validations attendent les réponses des différents serveurs standbys synchrones indiquant qu'elles ont reçus l'enregistrement de validation de la transaction et qu'elles l'ont appliqué, de façon à ce que le résultat soit visibles par les requêtes exécutées sur les standbys. Si configuré à remote_write, les validations attendent les réponses des standbys synchrones courants indiquant qu'elles ont reçu l'enregistrement de validation de la transaction et qu'elles l'ont donné au système d'exploitation pour écriture sur le disque. Cette configuration est suffisante pour s'assurer de la préservation des données même si l'instance standby de PostgreSQL devait s'arrêter brutalement, mais pas si le standby souffre d'un crash au niveau du système d'exploitation car les données n'ont pas forcément encore atteint un stockage stable sur le standby. Enfin, la configuration local force les validations à attendre que les données soient enregistrées sur disque, localement, mais pas répliquées. Ceci n'est généralement pas souhaitable lors de l'utilisation d'une réplication synchrone mais est proposé pour offrir une solution complète.

Si synchronous_standby_names est vide, les configurations on, remote_apply, remote_write et local fournissent toutes le même niveau de synchronisation : les validations de transactions attendent seulement l'enregistrement local sur disque.

Ce paramètre peut être changé à tout moment ; le comportement pour toute transaction est déterminé par la configuration en cours lors de la validation. Il est donc possible et utile d'avoir certaines validations validées en synchrone et d'autres en asynchrone. Par exemple, pour réaliser une validation asynchrone de transaction à plusieurs instructions avec une valeur par défaut inverse, on exécute l'instruction SET LOCAL synchronous_commit TO OFF dans la transaction.

Recommandations [EN]

If data integrity is less important to you than response times (for example, if you are running a social networking application or processing logs) you can turn this off, making your transaction logs asynchronous. This can result in up to wal_buffers or wal_writer_delay * 2 worth of data in an unexpected shutdown, but your database will not be corrupted. Note that you can also set this on a per-session basis, allowing you to mix “lossy” and “safe” transactions, which is a better approach for most applications.

Commentaires