Voir aussi la Section 26.3, « Configuration de journaux de transaction » pour des détails sur la configuration pointue des WAL.
Si cette option est activée, le serveur PostgreSQL™ tentera de s'assurer que les mises à jour sont écrites physiquement sur le disque en exécutant les appels système fsync() ou différentes méthodes équivalentes (voir wal_sync_method). Ceci vous assure que le groupe de bases de données retournera à un état cohérent après un arrêt brutal du système d'exploitation ou suite à un problème matériel.
Néanmoins, utiliser fsync() implique des coûts au niveau performance : lorsqu'une transaction est validée, PostgreSQL™ doit attendre que le système d'exploitation vide les WAL sur disque. Lorsque fsync est désactivé, le système d'exploitation est autorisé à faire de son mieux en utilisant des tampons pour les écritures, en ordonnant et en ajoutant des délais aux écritures. Néanmoins, si le système s'arrête brutalement, les résultats des dernières transactions validées pourraient être perdus en partie ou complètement. Dans le pire des cas, une corruption non récupérable des données pourrait survenir (les arrêts brutaux du serveur de bases de données lui-même ne sont pas un facteur de risque ici. Seul l'arrêt brutal au niveau du système d'exploitation crée un risque de corruption).
À cause des risques encourus, il n'existe pas de paramétrage universel pour fsync. Certains administrateurs désactivent en permanence fsync alors que d'autres ne le désactivent que pour les charges initiales importantes de données s'il existe un moyen de recommencer proprement si quelque chose se passe mal. D'autres laissent toujours fsync activé. La valeur par défaut est d'activer fsync pour une confiance maximale. Si vous avez confiance en votre système d'exploitation (ou sur la sauvegarde sur batterie), vous pouvez considérer la désactivation de fsync.
Cette option est configurable au lancement du serveur et dans le fichier postgresql.conf. Si vous désactivez cette option (off), considérez aussi la désactivation de full_page_writes.
Méthode utilisée pour forcer les mises à jour des WAL sur le disque. Si fsync est désactivé, alors ce paramètre est inapplicable car les mises à jour ne seront pas du tout forcées. Les valeurs possibles sont :
open_datasync (écrit les fichiers WAL avec l'option O_DSYNC de open())
fdatasync (appelle fdatasync() à chaque validation)
fsync (appelle fsync() à chaque validation)
fsync_writethrough (appelle fsync() à chaque validation, forçant une écriture de tous les caches disque)
open_sync (écrit les fichiers WAL avec l'option O_SYNC de open())
Toutes ces options ne sont pas disponibles sur toutes les plateformes. Par défaut, elle correspond à la première méthode supportée par la plateforme parmi celles de la liste ci-dessus. La seule exception concerne le système Linux dont la valeur par défaut est fdatasync. Cette option est configurable au lancement du serveur et dans le fichier postgresql.conf.
Quand cette option est activée, le serveur PostgreSQL™ écrit le contenu entier de chaque page disque sur un WAL lors de la première modification de cette page intervenant après un point de vérification.
Ce paramètre est actuellement ignoré (traité comme valant toujours on) car le désactiver peut causer des échecs lors de la récupération après un arrêt brutal, même quand aucune erreur matérielle ou du système d'exploitation n'est survenue. Ceci pourra être corrigé dans une version future. Sinon, le paramètre pourra être complètement supprimé.
Nombre de tampons de pages disque alloués en mémoire partagée pour les données WAL. La valeur par défaut vaut 8. Ce paramétrage a seulement besoin d'être assez important pour contenir toutes les données WAL générées par une transaction typique car la donnée est envoyée sur le disque à chaque validation de transaction. Cette option est seulement disponible au lancement du serveur.
Augmenter ce paramètre peut causer une demande plus importante de tampons partagés System V par PostgreSQL™, plus que ne le permet la configuration par défaut de votre système d'exploitation. Voir la Section 16.4.1, « Mémoire partagée et sémaphore » pour des informations sur la façon d'ajuster ces paramètres, si nécessaire.
Délai entre l'enregistrement d'une validation dans le tampon WAL et le vidage du tampon sur le disque, en microsecondes. Un délai différent de zéro peut autoriser la validation de plusieurs transactions sur un seul appel système fsync() si la charge système est assez importante pour que des transactions supplémentaires soient prêtes dans l'intervalle donné. Mais le délai est perdu si aucune autre transaction n'est prête à être validée. Du coup, le délai n'est traité que si au moins commit_siblings autres transactions sont actives au moment où le processus serveur a écrit son enregistrement de validation. La valeur par défaut est zéro, donc pas de délai.
Nombre minimum de transactions ouvertes en même temps avant d'attendre le délai commit_delay. Une valeur plus importante rend plus probable le fait qu'au moins une autre transaction sera prête à valider pendant la durée du délai. La valeur par défaut est de cinq.
Distance maximum entre des points de vérifications automatiques des WAL, dans les segments des journaux de traces (chaque segment fait normalement 16 Mo). Par défaut, il y en a trois. Cette option n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf.
Temps maximum entre des points de vérification automatiques des WAL en secondes. La valeur par défaut est de 300 secondes. Cette option n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf.
Écrit un message dans les journaux du serveur si les points de vérification causées par le remplissage des fichiers segment sont arrivés dans un intervalle plus rapide que ce nombre de secondes (ce qui suggère que checkpoint_segments devrait être augmenté). Vaut par défaut 30 secondes. Une valeur de zéro désactive cet avertissement.
La commande shell pour exécuter l'archivage d'un segment complet de fichier WAL. Si cette chaîne est vide (valeur par défaut), l'archivage des WAL est désactivé. Tout %p dans la chaîne est remplacé par le chemin vers le fichier à archiver et tout %f est seulement remplacé par le nom du fichier. (Le chemin est relatif au répertoire courant du serveur, c'est-à-dire le répertoire des données du cluster.) Utilisez %% pour intégrer un vrai caractère % dans la commande. Pour plus d'informations, voir la Section 23.3.1, « Configurer l'archivage WAL ». Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.
Il est important que la commande renvoie un code de sortie zéro si et seulement si elle a réussi. Exemples :
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"' archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
Consommation de ressources