Voir aussi la Section 27.3, « Configuration de journaux de transaction » pour les détails concernant l'optimisation des des WAL.
Si ce paramètre est activé, le serveur PostgreSQL™ tente de s'assurer que les mises à jour sont écrites physiquement sur le disque en exécutant des appels système fsync() ou toute autre méthode équivalente (voir wal_sync_method). Ceci permet de s'assurer que le cluster de bases de données peut revenir à un état cohérent après une panne matérielle ou du système d'exploitation.
Toutefois, l'utilisation de fsync() a un impact sur les performances : 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 dans la mise en tampons, l'ordonnancement et le report des écritures. Cependant, en cas de panne système, les résultats des dernières transactions validées peuvent être en partie, voire complètement, perdus. Dans le pire des cas, une corruption irrécupérable des données peut survenir. (Une panne du serveur de bases de données lui-même ne représente pas ici un facteur de risque. Seul une panne système engendre un risque de corruption.)
Du fait 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 chargements initiaux importants de données puisqu'il existe un point de redémarrage clairement défini si quelque chose se passe mal. D'autres laissent fsync en permanence activé. Par défaut, il est préférable d'activer fsync pour une bénéficier d'une sécurité maximale. Si le système d'exploitation, le matériel et la compagnie d'électricité (ou la sauvegarde sur batterie) sont dignes de confiance, la désactivation de fsync peut être envisagée.
Ce paramètre ne peut être configuré que dans le fichier postgresql.conf ou indiqué sur la ligne de commande. Si ce paramètre est désactivé (off), il est intéressant de désactiver aussi 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 sont 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 en écriture)
open_sync (écrit les fichiers WAL avec l'option O_SYNC de open())
Les options open_* utilisent aussi O_DIRECT s'il est disponible. Toutes ces options ne sont pas disponibles sur toutes les plateformes. La valeur par défaut est la première méthode de la liste ci-dessus supportée par la plateforme, sauf sur Linux où fdatasync est la valeur par défaut. Ce paramètre ne peut être configuré que dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Quand ce paramètre est activé, le serveur PostgreSQL™ écrit l'intégralité du contenu de chaque page disque dans les WAL lors de la première modification de cette page intervenant après un point de vérification. Ceci est nécessaire car une écriture de page en cours alors que survient une panne du système d'exploitation peut n'être que partiellement effectuée, ce qui conduit à à une page sur disque qui contient un mélange d'anciennes et de nouvelles données. Les données de modification de niveau ligne stockées habituellement dans les WAL ne sont pas suffisantes pour restaurer complètement une telle page lors de la récupération d'après panne. Le stockage l'image de la page complète garantit une restauration correcte de la page, mais au prix d'un accroissement de la quantité de données à écrire dans les WAL. (Parce que la relecture des WAL démarre toujours à un point de vérification, il est suffisant de faire cela lors de la première modification de chaque page survenant après un point de vérification. De ce fait, une façon de réduire le coût d'écriture de pages complètes consiste à augmenter le paramètre réglant les intervalles entre points de vérification.)
La désactivation de ce paramètre accélère les opérations normales, mais peut aboutir à la corruption de la base de données après une panne du système d'exploitation ou une coupure de courant. Les risques sont similaires à la désactivation de fsync, bien que moindres. Ce paramètre pourrait être désactivé sans risque si le matériel (contrôleur disque sur batterie) ou le logiciel de gestion du système de fichiers (ReiserFS 4) réduit le risque d'écritures partielles de pages à un niveau suffisamment bas.
La désactivation de ce paramètre n'affecte pas l'utilisation de l'archivage des WAL pour la récupération d'un instantané, aussi appelé PITR (voir Section 23.3, « Archivage continu et récupération d'un instantané (PITR) »).
Ce paramètre ne peut être configuré que dans le fichier postgresql.conf ou indiqué sur la ligne de commande. Activé par défaut (on).
Quantité de mémoire utilisée en mémoire partagée pour les données WAL. La valeur par défaut est de 64 Ko. Ce paramètre nécessite uniquement d'être assez important pour contenir toutes les données WAL engendrées par une transaction typique, car les données sont écrites sur le disque à chaque validation de transaction. Ce paramètre n'est ajustable qu'au lancement du serveur.
L'augmentation de ce paramètre peut conduire PostgreSQL™ à réclamer plus de tampons partagés System V que ne le permet la configuration par défaut du système d'exploitation. Voir la Section 16.4.1, « Mémoire partagée et sémaphore » pour les 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 en 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, soit pas de délai.
Nombre minimum de transactions concurrentes ouvertes en même temps nécessaires avant d'attendre le délai commit_delay. Une valeur plus importante rend plus probable le fait qu'au moins une autre transaction soit prête à valider pendant le délai. La valeur par défaut est de cinq transactions.
Distance maximale entre deux points de vérification automatique des WAL, en segments de fichier de traces (chaque segment fait normalement 16 Mo). La valeur par défaut est de trois segments. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Temps maximum entre deux points de vérification automatique des WAL, en secondes. La valeur par défaut est de cinq minutes. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Si deux points de vérification imposés par le remplissage des fichiers segment interviennent dans un délai plus court que celui indiqué par ce paramètre (ce qui laisse supposer qu'il faut augmenter la valeur du paramètre checkpoint_segments), un message est écrit dans le fichier de traces du serveur. Par défaut, 30 secondes. Une valeur nulle (0) désactive cet avertissement. Ce paramètre ne peut être configuré que dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
La commande shell à exécuter pour archiver un segment complet de la série des fichiers 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 du fichier à archiver et tout %f par le seul nom du fichier. (Le chemin est relatif au répertoire de travail du serveur, c'est-à-dire le répertoire de données du cluster.) %% est utilisé pour intégrer un caractère % dans la commande. Pour plus d'informations, voir la Section 23.3.1, « Configurer l'archivage WAL ». Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Il est important que la commande ne renvoie un code de sortie nul que si, et seulement si, elle réussit. Exemples :
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"' archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
Le archive_command n'est appelé que pour les segments WAL complets. De ce fait, si le serveur n'engendre que peu de trafic WAL (ou que cela arrive parfois), il se peut qu'un long moment s'écoule entre la fin d'une transaction et son archivage sécurisé. Pour limiter l'âge des données non encore archivées, archive_timeout peut être configuré pour forcer le serveur à basculer périodiquement sur un nouveau segment WAL. Lorsque ce paramètre est positif, le serveur bascule sur un nouveau segment à chaque fois que archive_timeout secondes se sont écoulées depuis le dernier changement de segment. Les fichiers archivés clos par anticipation suite à une bascule imposée sont toujours de la même taille que les fichiers complets. Il est donc déconseillé de configurer un temps très court pour archive_timeout -- cela va faire exploser la taille du stockage des archives. Un paramétrage d'archive_timeout de l'ordre de la minute est habituellement raisonnable. Ce paramètre ne peut être configuré que dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Consommation des ressources