16.4. Configuration à l'exécution

Il existe un grand nombre de paramètres de configuration affectant le comportement du système de bases de données. Dans cette sous-section, nous décrivons comment configurer ces paramètres ; les sections suivantes discutent de chaque paramètre en détail.

Tous les noms de paramètres ne sont pas sensibles à la casse. Chaque paramètre prend une valeur d'un de ces quatre types : booléen, entier, nombre à virgule flottante ou chaîne de caractères. Les valeurs booléennes peuvent être saisies comme ON, OFF, TRUE, FALSE, YES, NO, 1, 0 (quelque soit la casse) ou tout préfixe non ambigu de ceux-ci.

Une façon d'initialiser ces paramètres est d'éditer le fichier postgresql.conf qui est normalement placé dans le répertoire data (initdb y installe une copie par défaut). Voici un exemple de ce que ce fichier peut contenir :

# Ceci est un commentaire
log_connections = yes
log_destination = 'syslog'
search_path = '$user, public'

Un seul paramètre est spécifié par ligne. Le signe égal entre le nom et la valeur est optionnel. Les espaces blancs n'ont pas de signification et les lignes blanches sont ignorées. Les marques de hachage (#) introduisent des commentaires. Les valeurs des paramètres qui ne sont pas des identifieurs simples ou des nombres doivent être entre des guillemets simples.

Le fichier de configuration est relu à chaque fois que le processus postmaster reçoit un signal SIGHUP (qui est envoyé par un simple appel à pg_ctl reload). Le postmaster propage aussi ce signal aux processus serveur en cours d'exécution de façon à ce que les sessions existantes obtiennent aussi la nouvelle valeur. Autrement, vous pouvez envoyer le signal directement à un seul processus serveur. Quelques paramètres peuvent seulement être initialisés au lancement du serveur ; tout changement dans leur entrée du fichier de configuration sera ignoré jusqu'au prochain lancement du serveur.

Une autre façon de configurer ces paramètres est de les donner en option sur la ligne de commande de postmaster ainsi :

postmaster -c log_connections=yes -c log_destination='syslog'

Les options de la ligne de commande surchargent tout paramétrage en conflit avec ceux du fichier postgresql.conf. Notez que cela signifie que vous ne pourrez pas modifier la valeur en direct en éditant simplement le fichier postgresql.conf, donc bien que la méthode de la ligne de commande soit agréable, cela peut vous coûter cher plus tard en flexibilité.

Occasionnellement, il est utile de donner une option en ligne de commande à une session particulière seulement. La variable d'environnement PGOPTIONS peut être utilisée dans ce but du côté client :

env PGOPTIONS='-c geqo=off' psql

(Ceci fonctionne pour toute application client basée sur libpq, et non pas seulement pour psql.) Notez que ceci ne fonctionnera pas pour les paramètres fixes lorsque le serveur est lancé ou qui doivent être spécifiés dans postgresql.conf.

De plus, il est possible d'affecter un ensemble de paramètres à un utilisateur d'une base de données. Quand une session est lancée, les paramétrages par défaut de l'utilisateur et de la base de données impliqués sont chargés. Les commandes ALTER USER et ALTER DATABASE, respectivement, sont utilisées pour configurer ces paramétrages. Les paramètres par base de données surcharge tous ceux reçus de la ligne de commande de postmaster ou du fichier de configuration, et sont aussi surchargés par ceux de l'utilisateur ; les deux sont surchargés par les options par session.

Quelques paramètres peuvent être changés dans des sessions SQL individuelles avec la commande SET, par exemple :

SET ENABLE_SEQSCAN TO OFF;

Si SET est autorisé, il surcharge toutes les autres sources de valeurs pour le paramètre. Quelques paramètres ne peuvent pas être changés via SET : par exemple, s'ils contrôlent un comportement qui ne peut pas être changé raisonnablement sans relancer PostgreSQL. De plus, quelques paramètres peuvent être modifiés via SET ou ALTER par les superutilisateurs, mais pas par des utilisateurs ordinaires.

La commande SHOW permet une inspection des valeurs actuelles de tous les paramètres.

La table virtuelle pg_settings (décrite dans la Section 41.35) autorise aussi l'affichage et la mise à jour de paramètres de session à l'exécution. Elle est équivalente à SHOW et SET mais peut être plus agréable à utiliser parce qu'elle peut être jointe avec d'autres tables ou sélectionnée avec l'utilisation des conditions de sélection désirées.

16.4.1. Emplacement des fichiers

En plus du fichier postgresql.conf déjà mentionné, PostgreSQL utilise deux autres fichiers de configuration édités manuellement, contrôlant l'authentification du client (leur utilisation est discuté dans Chapitre 19). Par défaut, les trois fichiers de configuration sont stockés dans le répertoire data du groupe des bases de données. Les options décrites dans cette sous-section permettent de déplacer les fichiers de configuration. (Faire ceci peut faciliter l'administration. En particulier, il est souvent plus simple de s'assurer que les fichiers de configuration sont proprement sauvegardés quand ils sont conservés à part.)

data_directory (string)

Spécifie le répertoire à utiliser pour le stockage des données. Cette option peut seulement être initialisée au lancement du serveur.

config_file (string)

Spécifie le fichier de configuration principal du serveur (appelé postgresql.conf). Cette option peut seulement être initialisée sur la ligne de commande de postmaster.

hba_file (string)

Spécifie le fichier de configuration pour l'authentification basée sur l'hôte (appelé pg_hba.conf). Cette option peut seulement être initialisée au lancement du serveur.

ident_file (string)

Spécifie le fichier de configuration pour l'authentification ident (appelé pg_ident.conf). Cette option peut seulement être initialisée au lancement du serveur.

external_pid_file (string)

Spécifie le nom d'un fichier supplémentaire par identifiant de processus (PID) que postmaster doit créer à l'intention des programmes d'administration du serveur. Cette option peut seulement être initialisée au lancement du serveur.

Dans une installation par défaut, aucune des options ci-dessus n'est configurée explicitement. À la place, le répertoire des données est spécifié par l'option -D en ligne de commande ou par la variable d'environnement PGDATA, et les fichiers de configuration sont tous disponibles dans le répertoire des données.

Si vous souhaitez conserver les fichiers de configuration ailleurs, l'option -D en ligne de commande du postmaster ou la variable d'environnement PGDATA doit pointer sur le répertoire contenant les fichiers de configuration. L'option data_directory doit être configurée à postgresql.conf (ou sur la ligne de commande) pour montrer où est situé le répertoire des données. Notez que data_directory surcharge -D et PGDATA quant à l'emplacement du répertoire des données, mais pas pour l'emplacement des fichiers de configuration.

Si vous le souhaitez, vous pouvez spécifier les noms des fichiers de configuration et leur emplacement individuellement en utilisant les options config_file, hba_file et/ou ident_file. config_file peut seulement être spécifié sur la ligne de commande de postmaster mais les autres peuvent être placés dans le fichier de configuration principal. Si les trois options et data_directory sont configurés explicitement, alors il n'est pas nécessaire de spécifier -D ou PGDATA.

Lors de la configuration de ces options, un chemin relatif sera interprété suivant le répertoire d'où est lancé postmaster.

16.4.2. Connexions et authentification

16.4.2.1. Paramétrages de connexion

listen_addresses (string)

Spécifie les adresses TCP/IP sur lesquelles le serveur écoute les connexions des applications client. La valeur prend la forme d'une liste de noms d'hôte ou d'adresses IP numériques séparés par des virgules. L'entrée spéciale * correspond à toutes les interfaces IP disponibles. Si la liste est vide, le serveur n'écoute aucune interface IP, auquel cas seuls les sockets de domaine Unix peuvent être utilisés pour s'y connecter. La valeur par défaut est localhost, ce qui autorise seulement les connexions locales de type << loopback >>. Ce paramètre peut seulement être configuré au lancement du serveur.

port (integer)

Le port TCP sur lequel le serveur écoute ; 5432 par défaut. Notez que le même numéro de port est utilisé pour toutes les adresses IP où le serveur écoute. Ce paramètre peut seulement être configuré au lancement du serveur.

max_connections (integer)

Détermine le nombre maximum de connexions concurrentes au serveur de la base de données. La valeur par défaut typique est 100 mais pourrait être bien moindre si vos paramétrages du noyau ne le supportent pas (ce qui est déterminé lors du initdb). Ce paramètre peut seulement être initialisé au lancement du serveur.

Augmenter ce paramètre pourrait faire que PostgreSQL réclame plus de mémoire partagée System V ou de sémaphores que ne le permet la configuration par défaut de votre système d'exploitation. Voir la Section 16.5.1 pour plus d'informations sur la façon d'ajuster ces paramètres si nécessaire.

superuser_reserved_connections (integer)

Détermine le nombre de connexions (<< slots >>) réservés aux connexions des superutilisateurs PostgreSQL. Au plus max_connections connexions peuvent être actives simultanément. À chaque fois que le nombre de connexions actives en même temps est d'au moins max_connections moins superuser_reserved_connections, les nouvelles connexions ne seront acceptées que pour les superutilisateurs.

La valeur par défaut est de 2. La valeur doit être plus petite que la valeur de max_connections. Ce paramètre peut seulement être configuré uniquement au lancement du serveur.

unix_socket_directory (string)

Spécifie le répertoire du socket de domaine Unix sur lequel le serveur écoute les connexions des applications clients. Par défaut, il s'agit de /tmp mais cela peut être modifié au moment de la construction. Ce paramètre peut seulement être configuré au lancement du serveur.

unix_socket_group (string)

Configure le groupe propriétaire du socket de domaine Unix (l'utilisateur propriétaire de la socket est toujours l'utilisateur qui lance le serveur). En combinaison avec l'option unix_socket_permissions, ceci peut être utilisé comme un mécanisme de contrôle d'accès supplémentaire pour les connexions de domaine Unix. Par défaut, il s'agit d'une chaîne vide utilisant le groupe par défaut pour l'utilisateur en cours. Cette option est seulement disponible au lancement du serveur.

unix_socket_permissions (integer)

Configure les droits d'accès au socket de domaine Unix. Ce socket utilise l'ensemble habituel des droits du système de fichiers Unix. La spécification de l'option est attendue dans le mode numérique avec la forme acceptée par les appels système chmod et umask (pour utiliser le format octal, ce nombre doit commencer avec un 0 (zéro)).

Les droits par défaut sont 0777, signifiant que tout le monde peut se connecter. Les alternatives raisonnables sont 0770 (seul l'utilisateur et le groupe, voir aussi unix_socket_group) et 0700 (seul l'utilisateur) (notez, que pour un socket de domaine Unix, seul le droit d'accès en écriture importe et, donc, il n'est pas nécessaire de donner ou de révoquer les droits de lecture ou d'exécution).

Ce mécanisme de contrôle d'accès est indépendant de celui décrit dans le Chapitre 19.

Cette option est seulement disponible au lancement du serveur.

rendezvous_name (string)

Spécifie le nom broadcast de Rendezvous. Par défaut, le nom de l'ordinateur est utilisé, spécifié comme une chaîne vide. Cette option est ignorée si le serveur n'était pas compilé avec le support Rendezvous. Cette option est seulement configurable au lancement du serveur.

16.4.2.2. Sécurité et authentification

authentication_timeout (integer)

Temps maximum pour terminer l'authentification du client en secondes. Si un client n'a pas terminé le protocole d'authentification dans ce délai, le serveur rompt la connexion. Ceci protège le serveur des clients bloqués occupant une connexion indéfiniment. Cette option n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf. La valeur par défaut est de 60 secondes.

ssl (boolean)

Active les connexions SSL. Merci de lire Section 16.8 avant d'utiliser ceci. C'est désactivé par défaut. Ce paramètre est seulement disponible au lancement du serveur.

ssl_renegotiation_limit (integer)

Indique la quantité de données pouvant transiter sur une connexion en SSL avant qu'une renégotiation de la session ne survienne. La renégotiation de la session diminue le risque d'analyse du chiffrement lorsque de gros volumes de données sont envoyées mais cela a un coût important pour les performances. Les données émises et réceptionnées sont prises en compte lors de la vérification de la limite. Si ce paramètre est à 0, la renégotiation est désactivée. La valeur par défaut est de 512 Mo.

Note : Les bibliothèques SSL antérieures à novembre 2009 ne sont pas sécurisées lors de l'utilisation de la renégotiation SSL à cause d'une faille dans le protocole SSL. Pour corriger rapidement cette faille, certains fournisseurs de la bibliothèque ont proposé des bibliothèques SSL ne disposant plus de la fonctionnalité de renégotiation. Si une de ces bibliothèques sont utilisées sur le serveur ou sur le client, la renégotiation SSL doit être désactivée.

password_encryption (boolean)

Cette option détermine si le mot de passe doit être crypté quand un mot de passe est spécifié dans CREATE USER ou ALTER USER sans écrire soit ENCRYPTED soit UNENCRYPTED. Actif par défaut (crypte le mot de passe).

krb_server_keyfile (string)

Configure l'emplacement du fichier contenant la clé secrète du serveur Kerberos. Voir Section 19.2.3 pour des détails.

db_user_namespace (boolean)

Ceci autorise les noms d'utilisateur par base de données. Désactivé par défaut.

Si cette option est activée, vous devrez créer des utilisateurs de nom nomutilisateur@nom_base. Quand nomutilisateur est passé pour un client en cours de connexion, @ et le nom de la base de données est ajouté au nom de l'utilisateur et ce nom d'utilisateur spécifique à la base de données est recherché dans le serveur. Notez que lorsque vous créez des utilisateurs dont le nom contient un @ dans l'environnement SQL, vous devez mettre le nom entre guillemets.

Cette option activée, vous pouvez toujours créer des utilisateurs globaux ordinaires. Ajoutez simplement @ lors de la spécification du nom du client. Le @ sera supprimé avant de chercher le nom de l'utilisateur dans le serveur.

Note : Cette fonctionnalité est temporaire jusqu'à ce qu'une solution complète soit trouvée. Cette option sera supprimée.

16.4.3. Consomnation de ressources

16.4.3.1. Mémoire

shared_buffers (integer)

Initialise le nombre de tampons en mémoire partagée utilisés par le serveur de bases de données. La valeur par défaut est de 1000 mais pourrait être moindre si la configuration de votre noyau ne le supporte pas (c'est déterminé lors de l'exécution d'initdb). Chaque tampon fait 8192 octets sauf si une valeur différente de BLCKSZ a été choisie lors de la construction du serveur. Ce paramétrage doit valoir au moins 16, mais aussi au moins deux fois la valeur de max_connections ; néanmoins, des valeurs significativement plus importantes que ce minimum sont généralement nécessaires pour de bonnes performances. Des valeurs de quelques milliers sont recommandées pour des installations de production. Cette option n'est initialisable qu'au lancement du serveur.

Augmenter ce paramètre pourrait faire en sorte que PostgreSQL réclame plus de mémoire partagé System V que ce que la configuration par défaut de votre système d'exploitation ne peut gérer. Voir la Section 16.5.1 pour plus d'informations sur l'ajustement de ces paramètres si nécessaire.

work_mem (integer)

Spécifie la mémoire à utiliser pour les opérations de tri interne et pour les tables de découpage avant de basculer sur des fichiers temporaires sur disque. La valeur est spécifiée en Ko et vaut par défaut 1024 (soit 1 Mo). Notez que pour une requête complexe, plusieurs tris ou opérations de hachage pourraient être exécutés en parallèle ; chacun d'entre eux se verra autorisé à utiliser autant de mémoire que cette valeur indique avant de commencer à placer des données dans des fichiers temporaires. De plus, plusieurs sessions en cours d'exécution pourraient exécuter des opérations simultanément. Donc, la mémoire totale utilisée pourrait être plusieurs fois la valeur de work_mem ; il est nécessaire de conserver ce fait en tête lors du choix de cette valeur. Les opérations de tri sont utilisées pour ORDER BY, DISTINCT et les jointures d'assemblage. Les tables de découpage sont utilisées dans les jointures de découpage, les agrégations basées sur le découpage et le traitement des sous-requêtes IN.

maintenance_work_mem (integer)

Spécifie la mémoire maximum utilisée dans les opérations de maintenance telles que VACUUM, CREATE INDEX et ALTER TABLE ADD FOREIGN KEY. La valeur est spécifiée en Ko et vaut par défaut 16384 (soit 16 Mo). Comme une seule de ces opérations peut être exécutée à un moment donné sur une session de la base de données et qu'une installation n'en exécute pas beaucoup en même temps, il est possible d'initialiser cette variable à une valeur bien plus importante que work_mem. De gros paramétrages pourraient améliorer les performances sur les opérations VACUUM et pour la restauration des sauvegardes de bases de données.

max_stack_depth (integer)

Spécifie la profondeur maximum de la pile d'exécution du serveur. La configuration idéale pour ce paramètre est la limite actuelle de la pile forcée par le noyau (configurée par ulimit -s ou une commande locale équivalente), moins une marge de sécurité d'un Mo ou plus. La marge de sécurité est nécessaire parce que la profondeur de la pile n'est pas vérifiée dans chaque routine du serveur mais seulement dans les routines clés potentiellement récursives telles que l'évaluation d'une expression. Configurer ce paramètre à une valeur plus importante que la limite réelle du noyau signifiera qu'une fonction récursive peut arrêter brutalement un processus serveur individuel. Le paramétrage par défaut est de 2048 Ko (soit 2 Mo), ce qui est très petit et comporte peu de risques. Néanmoins, cela pourrait être trop petit pour autoriser l'exécution de fonctions complexes.

16.4.3.2. Carte de l'espace libre (Free Space Map)

max_fsm_pages (integer)

Initialise le nombre maximum de pages disque pour lesquelles les espaces libres sont tracés dans la carte partagée des espaces libres. Six octets de mémoire partagée sont consommés pour chaque emplacement de page. Ce paramétrage doit être supérieur à 16 * max_fsm_relations. Par défaut, il est à 20000. Cette option n'est configurable qu'au lancement du serveur.

max_fsm_relations (integer)

Initialise le nombre maximum de relations (tables et index) pour lesquelles les espaces libres sont tracés dans la carte partagée de l'espace libre. En gros, 50 octets de mémoire partagée sont consommés par emplacement. La valeur par défaut est de 1000. Cette option n'est configurable qu'au lancement du serveur.

16.4.3.3. Utilisation des ressources du noyau

max_files_per_process (integer)

Initialise le nombre maximum de fichiers ouverts simultanément permis pour chaque sous-processus serveur. La valeur par défaut est de 1000. Si le noyau force une limite par processus, vous n'avez pas besoin de vous inquiéter de ce paramétrage. Mais, sur certaines plateformes (notamment la plupart des systèmes BSD), le noyau autorisera des processus individuels à ouvrir beaucoup plus de fichiers que le système ne peut réellement supporter quand un grand nombre de processus essaient d'ouvrir autant de fichiers. Si vous récupérez des erreurs du type << Too many open files >> (trop de fichiers ouverts), essayez de réduire ce paramètre. Cette option peut aussi être configurée au lancement du serveur.

preload_libraries (string)

Cette variable spécifie une ou plusieurs bibliothèques préchargées au lancement du serveur. Une fonction d'initialisation sans paramètre peut être appelée pour chaque bibliothèque. Pour cela, ajouter un caractère deux points et le nom de la fonction d'initialisation après le nom de la bibliothèque. Par exemple, '$libdir/malib:malib_init' causerait le préchargement de malib et l'exécution de malib_init. Si plus d'une bibliothèque doit être chargée, séparez leur nom par des virgules.

Si une bibliothèque spécifique ou une fonction d'initialisation sont introuvables, le serveur échouera au lancement.

Les bibliothèques des langages de procédure de PostgreSQL peuvent être préchargées de cette façon, typiquement en utilisant la syntaxe '$libdir/plXXX:plXXX_init'XXX est soit pgsql soit perl soit tcl soit python.

En préchargeant une bibliothèque partagée (et en l'initialisant dans les cas applicables), le temps de lancement de la bibliothèque est évité à la première utilisation de la bibliothèque. Néanmoins, le temps de lancer chaque nouveau processus pourrait augmenter légèrement même si le processus n'utilise pas la bibliothèque. Donc, cette option est seulement recommandée pour les bibliothèques qui seront utilisées par la majorité des sessions.

16.4.3.4. Délais du VACUUM basé sur le coût

Lors de l'exécution des commandes VACUUM et de ANALYZE, le système maintient un compteur interne conservant la trace du coût estimé des différentes opérations d'entrées/sorties réalisées. Quand le coût accumulé atteint une limite (spécifiée par vacuum_cost_limit), le processus traitant l'opération s'arrêtera un moment (spécifié par vacuum_cost_delay). Puis, il réinitialisera le compteur et continuera l'exécution.

Le but de cette fonctionnalité est d'autoriser les administrateurs à réduire l'impact des entrées/sorties de ces commandes suivant l'activité des bases de données. Il existe un grand nombre de situations pour lesquelles ceci n'est pas très important mais les commandes de maintenance quand VACUUM et ANALYZE se finissent rapidement ; néanmoins, il est généralement très important que ces commandes n'interfèrent pas de façon significative sur la capacité du système à réaliser d'autres opérations sur les bases de données. Un délai du VACUUM basé sur le coût fournit un moyen aux administrateurs pour y parvenir.

Cette fonctionnalité est désactivée par défaut. Pour l'activer, initialisez la variable vacuum_cost_delay à une valeur différente de zéro.

vacuum_cost_delay (integer)

Le temps, en millisecondes, de repos du processus quand la limite de coût a été atteinte. La valeur par défaut vaut 0, ce qui désactive la fonctionnalité du délai du VACUUM basé sur le coût. Une valeur positive active cette fonctionnalité. Notez que, sur plusieurs systèmes, la résolution réelle des délais de repos est de 10 millisecondes ; configurer vacuum_cost_delay à une valeur qui n'est pas un multiple de 10 pourrait avoir le même résultat que de le configurer au prochain multiple de 10.

vacuum_cost_page_hit (integer)

Le coût estimé pour nettoyer via VACUUM un tampon trouvé dans le cache des tampons partagés. Cela représente le coût pour verrouiller le lot de tampons, la recherche dans la table de découpage partagée et le parcours du contenu de la page. La valeur par défaut vaut 1.

vacuum_cost_page_miss (integer)

Le coût estimé pour nettoyer via VACUUM un tampon qui doit être lu sur le disque. Ceci représente l'effort pour verrouiller le lot de tampons, la recherche dans la table de découpage partagée, la lecture du bloc désiré du disque et le parcours de son contenu. La valeur par défaut vaut 10.

vacuum_cost_page_dirty (integer)

Le coût estimé chargé quand VACUUM modifie un bloc qui était précédemment propre. Cela représente les entrées/sorties supplémentaires requis pour vider le bloc sale de nouveau sur le disque. La valeur par défaut vaut 20.

vacuum_cost_limit (integer)

Le coût accumulé qui causera l'endormissement du processus de VACUUM. La valeur par défaut vaut 200.

Note : Certaines opérations contenant des verrous critiques devraient se terminer aussi rapidement que possible. Les délais de VACUUM basés sur le coût ne surviennent pas pendant ces opérations. Du coup, il est possible que le coût accumulé soit bien plus important que la limite spécifiée. Pour éviter des délais inutilement longs dans de tels cas, le délai réel est calculé de la façon suivante : vacuum_cost_delay * accumulated_balance / vacuum_cost_limit avec un maximum de vacuum_cost_delay * 4.

16.4.3.5. Écriture en tâche de fond

À partir de PostgreSQL 8.0, il existe un processus serveur séparé pour l'écriture en tâche de fond, dont la seule fonction est de lancer les écritures des tampons partagés << sales >>. Le but est que les processus serveur gérant les requêtes des utilisateurs doivent déléguer ou n'avoir jamais à attendre la fin d'une écriture car le processus d'écriture en tâche de fond s'en chargera. Cet arrangement réduit aussi la pénalité de performance associée avec les points de vérification. Le processus d'écriture en tâche de fond vérifiera en contenu les pages sales pour les écrire sur le disque, de façon à ce que seules quelques pages doivent être forcées en écriture lorsque survient le point de vérification, à la place d'un déluge d'écritures de tampons sales ne se faisant qu'à chaque point de vérification. Néanmoins, il y a une nette augmentation dans la charge des entrées/sorties parce que, là où une page souvent sale n'aurait été écrite qu'une seule fois par intervalle de point de vérification, le processus d'écriture en tâche de fond l'aurait écrite plusieurs fois dans la même période. Dans la plupart des situations, un chargement lent continu est préférable à des pointes périodiques mais les paramètres discutés dans cette section peuvent être utilisés pour configurer finement le comportement pour les besoins locaux.

bgwriter_delay (integer)

Spécifie le délai entre les tours d'activité du processus d'écriture en tâche de fond. À chaque tour, le processus écrit un certain nombre de tampons sales (contrôlable par les paramètres suivants). Les tampons sélectionnées seront toujours ceux les moins récemment utilisés parmi les tampons sales en cours. Puis, il s'endort pour bgwriter_delay millisecondes et recommande. La valeur par défaut est de 200. Notez que sur de nombreux systèmes, la résolution réelle des délais de sommeil est de 10 millisecondes; configurer bgwriter_delay à une valeur qui n'est pas un multiple de 10 pourrait avoir le même résultat que de le configurer au multiple de 10 supérieur. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

bgwriter_percent (integer)

À chaque tour, pas plus que ce pourcentage de tampons sales ne seront écrits (ne terminant tout fraction sur le prochain nombre de tampons). La valeur par défaut est 1. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

bgwriter_maxpages (integer)

À chaque tour, pas plus que ce nombre de tampons partagés sera écrit. La valeur par défaut vaut 100. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

Des valeurs plus petites de bgwriter_percent et bgwriter_maxpages réduiront la charge supplémentaire en entrées/sorties causée par le processus d'écriture en tâche de fond mais laisseront plus de travail au point de vérification. Pour réduire les pointes de chargements aux points de vérification, augmentez les valeurs. Pour désactiver totalement le processus en d'écriture en tâche de fond, configurez bgwriter_percent et/ou bgwriter_maxpages à zéro.

16.4.4. Write Ahead Log

Voir aussi la Section 25.2 pour des détails sur la configuration pointue des WAL.

16.4.4.1. Paramétrages

fsync (boolean)

Si cette option est activée, le serveur PostgreSQL utilisera l'appel système fsync() à plusieurs endroits pour s'assurer que les mises à jour sont écrites physiquement sur le disque. 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 importantes s'il existe un moyen de recommencer proprement si quelque chose se passe mal. Mais d'autres administrateurs 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 n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf file.

wal_sync_method (string)

Méthode utilisée pour forcer les mises à jour des WAL sur le disque. Les valeurs possibles sont fsync (appel de fsync() à chaque validation), fdatasync (appel de fdatasync() à chaque validation), fsync_writethrough (appel de _commit() à chaque validation sur Windows), open_sync (écriture des fichiers WAL avec l'option O_SYNC de open()) et open_datasync (écriture des fichiers WAL avec l'option O_DSYNC de open()). Toutes ces options ne sont pas disponibles sur toutes les plateformes. Si fsync est désactivée, alors cette configuration n'a pas d'intérêt. Cette option n'est configurable qu'au lancement du serveur ou dans le fichier postgresql.conf.

wal_buffers (integer)

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. Cette option est seulement disponible au lancement du serveur.

commit_delay (integer)

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.

commit_siblings (integer)

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.

16.4.4.2. Points de vérification

checkpoint_segments (integer)

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.

checkpoint_timeout (integer)

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.

checkpoint_warning (integer)

É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. Vaut par défaut 30 secondes. Une valeur de zéro désactive cet avertissement.

16.4.4.3. Archivage

archive_command (string)

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 absolu vers le fichier à archiver et tout %f est seulement remplacé par le nom du fichier. Utilisez %% pour intégrer un vrai caractère % dans la commande. Pour plus d'informations, voir la Section 22.3.1. 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

16.4.5. Planification des requêtes

16.4.5.1. Configuration de la méthode du planificateur

Ces paramètres de configuration fournissent une méthode dure pour influencer les plans de requête choisis par l'optimiseur de requêtes. Si le plan choisi par défaut par l'optimiseur pour une requête particulière n'est pas optimale, une solution temporaire pourrait être découverte en utilisant un de ces paramètres de configuration pour forcer l'optimiseur à choisir un meilleur plan. Désactiver un de ces paramétrages de façon permanente est néanmoins quelque fois une bonne idée. De meilleures façons d'améliorer la qualité des plans choisis par l'optimiseur incluent l'ajustement de Constantes de coût du planificateur, le lancement plus fréquent de ANALYZE, l'augmentation de la valeur du paramètre de configuration default_statistics_target et l'augmentation du nombre de statistiques récupérées pour des colonnes spécifiques en utilisant ALTER TABLE SET STATISTICS.

enable_hashagg (boolean)

Active ou désactive l'utilisation des agrégats hachés par le planificateur. Actif par défaut.

enable_hashjoin (boolean)

Active ou désactive l'utilisation des jointures hachées par le planificateur. Actif par défaut.

enable_indexscan (boolean)

Active ou désactive l'utilisation des parcours d'index par le planificateur. Actif par défaut.

enable_mergejoin (boolean)

Active ou désactive l'utilisation des jointures de fusion par le planificateur. Actif par défaut.

enable_nestloop (boolean)

Active ou désactive l'utilisation des jointures de boucles imbriquées par le planificateur. Il n'est pas possible de supprimer les jointures de boucles imbriquées complètement mais désactiver cette variable décourage le planificateur de l'utiliser si d'autres méthodes sont disponibles. Actif par défaut.

enable_seqscan (boolean)

Active ou désactive l'utilisation des parcours séquentiel par le planificateur. Il n'est pas possible de supprimer complètement les parcours séquentiels mais désactiver cette variable décourage le planificateur de l'utiliser si d'autres méthodes sont disponibles. Actif par défaut.

enable_sort (boolean)

Active ou désactive l'utilisation des étapes de tri explicite par le planificateur. Il n'est pas possible de supprimer complètement ces tris mais désactiver cette variable décourage le planificateur de l'utiliser si d'autres méthodes sont disponibles. Actif par défaut.

enable_tidscan (boolean)

Active ou désactive l'utilisation des parcours de TID par le planificateur. Actif par défaut.

16.4.5.2. Constantes de coût du planificateur

Note : Malheureusement, il n'existe pas de méthode bien définie pour déterminer les valeurs idéales pour la famille des variables de coût (<< cost >>) qui apparaissent ci-dessous. Vous êtes encouragés à expérimenter et à partager vos découvertes.

effective_cache_size (floating point)

Configure l'idée du planificateur sur la taille réelle du cache disque disponible pour un simple parcours d'index. Ceci est factorisé en estimation du coût d'utilisation d'un index ; une valeur plus grande rend un parcours d'index plus probable, une valeur plus basse favorise le parcours séquentiel. Lors de la modification de ce paramètre, vous devez considérer les tampons partagés de PostgreSQL et la partie cache disque du noyau qui seront utilisés pour les fichiers de données de PostgreSQL. De plus, prenez en compte le nombre attendu de requêtes concurrentes utilisant différents index car elles devront partager l'espace disponible. Ce paramètre n'a pas d'effet sur la taille de la mémoire partagée allouée par PostgreSQL, pas plus qu'il ne réserve de cache disque du noyau ; c'est utilisé uniquement dans un but d'estimation. La valeur est mesurée en pages disque, qui sont normalement de 8192 octets chaque. La valeur par défaut est de 1000.

random_page_cost (floating point)

Initialise l'estimation du coût du planificateur pour une page disque récupérée de façon non séquentielle. C'est mesuré comme un multiple du coût de récupération d'une page séquentielle. Une valeur plus haute rend plus probable l'utilisation d'un parcours séquentiel, une valeur basse l'utilisation d'un parcours d'index. La valeur par défaut est quatre.

cpu_tuple_cost (floating point)

Initialise l'estimation du coût du planificateur pour le traitement de chaque ligne lors d'une requête. C'est mesuré comme une fraction du coût de la récupération séquentielle d'une page. La valeur par défaut est 0,01.

cpu_index_tuple_cost (floating point)

Initialise l'estimation du coût du planificateur pour le traitement de chaque ligne lors d'un parcours d'index. C'est mesuré comme une fraction du coût de la récupération séquentielle d'une page. La valeur par défaut est 0,001.

cpu_operator_cost (floating point)

Initialise l'estimation du coût du planificateur de requêtes pour le traitement de chaque opérateur dans une clause WHERE. C'est mesuré comme une fraction du coût de récupération séquentielle d'une page. La valeur par défaut est 0,025.

16.4.5.3. Optimiseur génétique de requêtes

geqo (boolean)

Active ou désactive l'optimisation génétique des requêtes, algorithme tentant de faire de la planification de requêtes sans recherche exhaustive. Activé par défaut. La variable geqo_threshold fournit un moyen plus fin pour désactiver certaines classes de requêtes.

geqo_threshold (integer)

Utilise l'optimisation génétique des requêtes pour planifier les requêtes avec au moins ce nombre d'éléments impliqués dans la clause FROM (notez qu'une construction JOIN externe compte seulement comme un élément du FROM). La valeur par défaut est de 12. Pour des requêtes simples, il est généralement préférable d'utiliser le planificateur déterministe, exhaustif mais pour les requêtes comprenant beaucoup de tables, le planificateur déterministe prendrait trop de temps.

geqo_effort (integer)

Contrôle l'équité entre le temps de planification et l'efficacité du plan de requête dans GEQO. Cette variable doit être un entier entre 1 et 10. La valeur par défaut est 5. Les valeurs plus importantes augmentent le temps passé pendant la planification de la requête mais augmentent aussi la possibilité qu'un plan de requête efficace soit choisi.

geqo_effort ne fait réellement rien directement ; c'est seulement utilisé pour calculer les valeurs par défaut des autres variables qui influencent le comportement de GEQO (décrit ci-dessous). Si vous préférez, vous pouvez configurer les autres paramètres manuellement.

geqo_pool_size (integer)

Contrôle la taille de la queue utilisée par GEQO. Cette taille est le nombre d'individus dans une population génétique. Elle doit être d'au moins deux, et les valeurs utiles sont typiquement 100 et 1000. Si elle est configurée à zéro (la valeur par défaut), alors une valeur par défaut convenable est choisie suivant geqo_effort et le nombre de tables dans la requête.

geqo_generations (integer)

Contrôle le nombre de générations utilisé par GEQO. Les générations spécifient le nombre d'itérations de l'algorithme. Il doit être au moins un, et les valeurs utiles sont dans la même échelle que la taille de la queue. S'il est configuré à zéro (la valeur par défaut), alors une version par défaut convenable est choisie suivant geqo_pool_size.

geqo_selection_bias (floating point)

Contrôle le biais de sélection utilisé par GEQO. C'est une pression sélective à l'intérieur de la population. Les valeurs peuvent aller de 1,50 à 2,00 ; ce dernier est la valeur par défaut.

16.4.5.4. Autres options du planificateur

default_statistics_target (integer)

Initialise la cible par défaut des statistiques pour les colonnes de table qui n'ont pas une cible spécifique de colonne configurée via ALTER TABLE SET STATISTICS. Des valeurs plus importantes accroissent le temps nécessaire à exécuter ANALYZE mais pourrait améliorer les estimations du planificateurs. La valeur par défaut est de 10. Pour plus d'informations sur l'utilisation des statistiques par le planificateur de requêtes de PostgreSQL, référez-vous à la Section 13.2.

from_collapse_limit (integer)

Le planificateur assemblera les sous-requêtes dans des requêtes supérieures si la liste FROM résultante n'aurait pas plus de ce nombre d'éléments. Des valeurs plus petites réduisent le temps de planification mais ramènent des plans de requêtes inférieurs. La valeur par défaut est huit. Il est généralement conseillé de conserver cette valeur inférieure à geqo_threshold.

join_collapse_limit (integer)

Le planificateur réécrira les constructions JOIN internes explicites en listes d'éléments FROM à chaque fois qu'une liste d'au plus ce nombre d'éléments au total en résulterait. Avant PostgreSQL 7.4, les jointures spécifiées via la construction JOIN ne seraient jamais réordonnées. Le planificateur de la requête a du coup été amélioré pour que les jointures internes écrites de cette forme puissent être ré-ordonnées ; ce paramètre de configuration contrôle à quel point ce ré-ordonnancement sera réalisé.

Note : À présent, l'ordre des jointures externes spécifiée via la construction JOIN n'est jamais ajusté par le planificateur de requêtes ; du coup, join_collapse_limit n'a aucun effet sur ce comportement. Le planificateur pourrait être amélioré pour ré-ordonner certaines classes de jointures externes dans une prochaine version de PostgreSQL.

Par défaut, cette variable est configurée de la même façon que from_collapse_limit, qui est approprié pour la plupart des utilisations. Configurer cette variable à 1 empêche le réordonnancement des JOINtures internes. Du coup, l'ordre de jointure explicite spécifiée dans la requête sera l'ordre réel dans lequel les relations sont jointes. Le planificateur de la requête ne choisit pas toujours l'ordre de jointure optimal ; les utilisateurs avancées pourraient choisir d'initialiser temporairement cette variable à 1, puis de spécifier l'ordre de jointure qu'ils désirent explicitement. Une autre conséquence en l'initialisant à 1 est que le planificateur de requêtes se comporte plus comme le planificateur de requête de PostgreSQL 7.3, ce que certains utilisateurs trouvent utile pour des raisons de compatibilités descendantes.

Configurer cette variable à une valeur entre 1 et from_collapse_limit pourrait être utile pour négocier entre le temps de planification et la qualité du plan choisie (les grandes valeurs produisent les meilleures plans).

16.4.6. Rapports d'erreur et traces

16.4.6.1. Où tracer

log_destination (string)

PostgreSQL supporte plusieurs méthodes pour la journalisation des messages du serveur, dont stderr et syslog. Sur Windows, eventlog est aussi supporté. Configurez cette option avec une liste de destinations désirées pour les journaux, séparées par des virgules. Par défaut, les traces vont seulement sur stderr. Cette option est seulement disponible au lancement du serveur et dans le fichier de configuration de postgresql.conf.

redirect_stderr (boolean)

Cette option autorise la capture et la redirection des messages envoyés vers stderr dans des journaux de traces. Cette option, en combinaison avec les traces stderr, est souvent plus utile que de tracer dans syslog car certains types de messages pourraient ne pas apparaître dans la sortie syslog (un exemple habituel concerne les messages d'échecs de l'éditeur de liens). Cette option est seulement disponible au lancement du serveur.

log_directory (string)

Quand redirect_stderr est activé, cette option détermine le répertoire dans lequel les fichiers de trace seront créés. Elle pourrait être spécifiée avec un chemin absolu ou relatif au répertoire des données du groupe. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

log_filename (string)

Quand redirect_stderr est activé, cette option initialise les noms des fichiers des journaux créés. La valeur est traitée comme un modèle strftime, du coup les échappements % peuvent être utilisés pour spécifier des noms de fichiers dépendant de l'heure. Si aucun échappement % n'est présent, PostgreSQL ajoutera l'époque de l'heure d'ouverture du nouveau journal. Par exemple, si log_filename valait server_log, alors le nom de fichier choisi serait server_log.1093827753 pour un journal commençant le dimanche 29 août 19:02:33 2004 MST. Cette option est seulement disponible au lancement du serveur ou dans le fichier de configuration postgresql.conf.

log_rotation_age (integer)

Quand redirect_stderr est activé, cette option détermine la durée de vie maximum d'un journal individuel. Après que cette durée se soit écoulée, un nouveau journal sera créé. Initialisez-la à zéro pour désactiver la création des nouveaux journaux suivant un délai. Cette option est seulement disponible au lancement du serveur ou dans le fichier de configuration postgresql.conf.

log_rotation_size (integer)

Quand redirect_stderr est activé, cette option détermine la taille maximum d'un journal individuel. Après ce nombre d'octets, un nouveau journal est créé. Initialiser cette taille à zéro désactive la création de nouveaux journaux suivant leur taille. Cette option est seulement disponible au lancement du serveur ou dans le fichier de configuration postgresql.conf.

log_truncate_on_rotation (boolean)

Quand redirect_stderr est activé, cette option fera que PostgreSQL tronque (surcharge), plutôt qu'il n'ajoute à un journal de même nom. Néanmoins, ce tronquage ne surviendra qu'à partir du moment où un nouveau fichier sera ouvert à cause d'une rotation basée sur le temps, et non pas suite au lancement du serveur ou suite à une rotation basée sur la taille. Si false, les fichiers déjà existants se verront ajoutés les nouvelles traces dans tous les cas. Par exemple, en utilisant cette option en combinaison avec un log_filename comme postgresql-%H.log résulterait en la génération de 24 journaux (un pour chaque heure) puis les surchargera cycliquement. Cette option est seulement disponible au lancement du serveur ou dans le fichier de configuration postgresql.conf.

Exemple : pour conserver sept jours de traces, un fichier par jour nommé server_log.Mon, server_log.Tue, etc. et surcharger automatiquement les traces de la semaine dernière avec ceux de cette semaine, configurez log_filename à server_log.%a, log_truncate_on_rotation à true et log_rotation_age à 1440.

Exemple : pour conserver 24 heures de traces, un journal par heure mais aussi, faire une rotation plus souvent si le journal dépasse 1 Go, configurez log_filename à server_log.%H%M, log_truncate_on_rotation à true, log_rotation_age à 60 et log_rotation_size à 1000000. Inclure %M dans log_filename permet des rotations conduites par la taille qui pourraient survenir pour sélectionner un nom de fichier différent du nom de fichier initial.

syslog_facility (string)

Lors que les traces syslog sont activées, cette option détermine le niveau (<< facility >>) utilisé par syslog. Vous pouvez choisir entre LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7 ; la valeur par défaut est LOCAL0. Voir aussi la documentation du démon syslog de votre serveur. Cette option ne se configure qu'au lancement du système.

syslog_ident (string)

Si syslog est activé, cette option détermine le nom du programme utilisé pour identifier les messages de PostgreSQL dans les journaux de traces de syslog. La valeur par défaut est postgres. Cette option ne se configure qu'au lancement du système.

16.4.6.2. Quand tracer

client_min_messages (string)

Contrôle les niveaux des messages envoyés au client. Les valeurs valides peuvent être DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING et ERROR. Chaque niveau inclut tous les niveaux qui le suivent. La valeur par défaut est NOTICE. Notez que LOG a un niveau différent que dans log_min_messages.

log_min_messages (string)

Contrôle les niveaux des messages écrits dans les journaux de traces. Les valeurs valides sont DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL et PANIC. Chaque niveau inclut tous les niveaux qui le suivent. Le niveau le plus bas obtient le plus petit nombre de messages. La valeur par défaut est NOTICE. Notez que LOG a un niveau différent que dans client_min_messages. Seuls les superutilisateurs peuvent modifier ce paramétrage.

log_error_verbosity (string)

Contrôle le nombre de détails écrits dans les journaux de traces pour chaque message tracé. Les valeurs valides sont TERSE, DEFAULT et VERBOSE, chacune ajoutant plus de champs aux messages affichés. Seuls les superutilisateurs peuvent modifier ce paramétrage.

log_min_error_statement (string)

Contrôle si l'instruction SQL ayant causé une erreur sera aussi enregistrée dans le journal des traces. Toutes les instructions SQL, qui causent une erreur du niveau spécifié ou d'un niveau plus haut, seront tracées. La valeur par défaut est PANIC (désactivant réellement cette fonctionnalité en production). Les valeurs valides sont DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, FATAL et PANIC. Par exemple, si vous l'initialisez à ERROR, alors toutes les instructions SQL causant des erreurs, fatales ou non, ou des paniques seront tracées. Activer cette option est utile pour localiser la source de toute erreur apparaissant dans le journal des traces. Seuls les superutilisateurs peuvent modifier ce paramétrage.

log_min_duration_statement (integer)

Initialise un temps d'exécution minimum (en millisecondes) pour que l'instruction soit tracée. Toutes les instructions SQL exécutées dans le temps imparti ou prenant plus de temps seront tracées avec leur durée. L'initialiser à zéro tracera toutes les requêtes avec leur durée. -1 (la valeur par défaut) désactive cette fonctionnalité. Par exemple, si vous la configurez à 250, toutes les instructions SQL s'exécutant en au moins 250 ms seront tracées. Activer cette option peut se révéler utile pour tracer les requêtes non optimisées dans vos applications. Seuls les superutilisateurs peuvent modifier ce paramétrage.

silent_mode (boolean)

Exécute le serveur silencieusement. Si cette option est configurée, le serveur se lancera automatiquement en tâche de fond et tout terminal de contrôle sera dissocié (même effet que l'option -S de postmaster). La sortie standard et la sortie standard des erreurs du serveur sont redirigées vers /dev/null, donc tout message qui leur est adressé sera perdu. Sauf si le journal syslog est sélectionné ou que redirect_stderr est activé, utiliser cette option n'est pas encouragé car il empêche de voir les messages d'erreurs.

Voici une liste des niveaux de sévérité utilisés dans ces paramétrages :

DEBUG[1-5]

Fournit des informations utiles aux développeurs.

INFO

Fournit des informations implicitement demandées par l'utilisateur, par exemple lors d'un VACUUM VERBOSE.

NOTICE

Fournit des informations qui pourraient être utiles aux utilisateurs, par exemple lors du tronquage d'identifiants longs ou la création d'index faisant partie de clés primaires.

WARNING

Fournit des avertissements aux utilisateurs, par exemple un COMMIT en dehors d'un bloc de transactions.

ERROR

Rapporte une erreur qui a annulé la commande en cours.

LOG

Rapporte des informations intéressant les administrateurs, par exemple l'activité des points de vérification.

FATAL

Rapporte une erreur qui a causé l'annulation de la session courante.

PANIC

Rapporte une erreur qui a causé l'annulation de toutes les sessions.

16.4.6.3. Que tracer

debug_print_parse (boolean)
debug_print_rewritten (boolean)
debug_print_plan (boolean)
debug_pretty_print (boolean)

Ces options activent plusieurs sorties de débogage. Pour chaque requête exécutée, elles affichent l'arbre d'analyse résultant. debug_pretty_print indente ces affichages pour produire un format de sortie plus lisible mais plus long. client_min_messages ou log_min_messages doivent valoir DEBUG1 ou plus bas pour réellement envoyer cette sortie vers le client ou les traces du serveur, respectivement. Ces options sont désactivées par défaut.

log_connections (boolean)

Ceci affiche une ligne dans les traces du serveur détaillant chaque connexion réussie. Désactivée par défaut, elle est probablement très utile. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.

log_disconnections (boolean)

Ceci affiche dans les journaux du serveur une ligne similaire à log_connections mais à la fin d'une session et inclut la durée de la session. Elle est désactivée par défaut. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.

log_duration (boolean)

Fait que la durée d'une instruction terminée satisfaisant log_statement est tracée. En utilisant cette option, si vous n'utilisez pas syslog, il est recommandé que vous traciez le PID ou l'ID de la session en utilisant log_line_prefix, de façon à ce que vous puissiez lier l'instruction à la durée en utilisant l'ID du processus ou de la session. Cette variable est désactivée par défaut. Seuls les superutilisateurs peuvent modifier ce paramétrage.

log_line_prefix (string)

Ceci est une chaîne style printf qui est affichée au début de chaque ligne de trace. La valeur par défaut est une chaîne vide. Chaque échappement reconnu est remplacé comme indiqué ci-dessous - tout ce qui reste et qui ressemble à un échappement est ignoré. Les autres caractères sont copiés directement sur la ligne. Certains échappements sont seulement reconnus par les processus de session et ne s'appliquent pas aux processus en tâche de fond comme le postmaster. Syslog produit son propre marquage horaire et informations d'ID sur le processus, donc vous ne voudrez probablement pas utiliser ces échappements si vous utilisez syslog. Cette option est seulement disponible au lancement du serveur et dans le fichier de configuration postgresql.conf.

ÉchappementEffetSession seulement
%uNom de l'utilisateuroui
%dNom de la base de donnéesoui
%rNom ou adresse IP de l'hôte distant et port distantoui
%pID du processusnon
%tMarquage horairenon
%iBalise de commande : la commande qui a généré cette trace.oui
%cID de session : un identifiant unique pour chaque session. Ce sont deux numéros hexadécimaux sur quatre octets (sans zéros devant) séparés par un point. Les nombres sont l'heure de début de la session et son ID de processus, donc ceci peut aussi être utilisé comme moyen de sauvegarde pour ces éléments.oui
%lNuméro de la ligne de traces pour chaque processus, commençant à 1non
%sMarquage horaire du début de sessionoui
%xID de la transactionoui
%qNe produit aucune sortie, mais indique aux autres processus de stopper à cet endroit dans la chaîne. Ignoré par les processus de session.non
%%Littéral %non

log_statement (string)

Contrôle les instructions SQL tracées. Les valeurs valides sont none, ddl, mod et all. ddl trace toutes les commandes de définition comme CREATE, ALTER et DROP. mod trace toutes les instructions ddl, plus INSERT, UPDATE, DELETE, TRUNCATE et COPY FROM. Les instructions PREPARE et EXPLAIN ANALYZE sont aussi tracées si leur commande contenue est d'un type approprié.

La valeur par défaut est none. Seuls les superutilisateurs peuvent changer ce paramétrage.

Note : L'instruction EXECUTE n'est pas considérée comme une instruction ddl ou mod. Quand elle est tracée, seul le nom de l'instruction préparée est rapporté, pas l'instruction préparée réelle.

Quand une fonction est définie dans le langage côté serveur PL/pgSQL, toute requête exécutée par la fonction sera seulement tracée la première fois que la fonction est appelée d'une session particulière. Ceci est dû au fait que PL/pgSQL conserve un cache des plans de requête produits par les instructions SQL dans la fonction.

log_hostname (boolean)

Par défaut, les messages de traces de connexion affichent seulement l'adresse IP de l'hôte se connectant. Activer cette option causera la trace du nom de l'hôte. Notez que, suivant votre configuration de résolution de nom d'hôte, ceci pourrait imposer une pénalité de performance non négligeable. Cette option est seulement disponible au lancement du serveur ou dans le fichier postgresql.conf.

16.4.7. Statistiques d'exécution

16.4.7.1. Surveillance des statistiques

log_statement_stats (boolean)
log_parser_stats (boolean)
log_planner_stats (boolean)
log_executor_stats (boolean)

Pour chaque requête, écrit les statistiques de performance du module respectif dans les journaux de trace. Ceci est un outil brut de profilage. log_statement_stats rapporte les statistiques totales sur les instructions alors que les autres rapportent des statistiques par module. log_statement_stats ne peut pas être activé avec toute option par module. Toutes ces options sont désactivées par défaut. Seuls les superutilisateurs peuvent modifier ces paramétrages.

16.4.7.2. Collecteur des statistiques sur les requêtes et les index

stats_start_collector (boolean)

Contrôle si le serveur doit lancer le sous-processus de récupération de statistiques. Il est activé par défaut mais pourrait être enlevé si vous n'avez aucun intérêt dans la récupération de statistiques.

stats_command_string (boolean)

Active la récupération de statistiques sur les commandes en cours d'exécution par chaque session, avec le moment de l'exécution de la commande. Cette option est désactivée par défaut. Notez que, même après son activation, cette information n'est pas visible par tous les utilisateurs, mais seulement par les superutilisateurs et l'utilisateur possédant la session. Donc, cela ne devrait pas représenter un risque de sécurité. La donnée est accessible via la vue système pg_stat_activity ; référez-vous au Chapitre 23 pour plus d'informations.

stats_block_level (boolean)

Active la récupération des statistiques au niveau bloc sur l'activité de la base de données. Cette option est désactivée par défaut. Si cette option est activée, les données produites sont accessibles via la famille de vues système pg_stat et pg_statio ; référez-vous au Chapitre 23 pour plus d'informations.

stats_row_level (boolean)

Active la récupération de statistiques au niveau ligne sur l'activité de la base de données. Cette option est désactivée par défaut. Si cette option est activée, les données produites sont accessibles via la famille de vues système pg_stat et pg_statio ; référez-vous au Chapitre 23 pour plus d'informations.

stats_reset_on_server_start (boolean)

Si elle est activée, les statistiques récupérées sont vidées à chaque fois que le serveur est redémarré. Dans le cas contraire, les statistiques sont cumulées après les redémarrages de serveur. Actif par défaut. Cette option peut seulement être configuré au lancement du serveur.

16.4.8. Valeurs par défaut des connexions client

16.4.8.1. Comportement des instructions

search_path (string)

Cette variable spécifie l'ordre dans lequel les schémas sont recherchés lorsqu'un objet (table, type de données, fonction, etc.) est référencé par un simple nom sans son composant schéma. Quand il existe des noms identiques dans différents schémas, le premier trouvé dans le chemin de recherche est utilisé. Un objet qui ne fait partie d'aucun des schémas du chemin de recherche peut seulement être référencé en spécifiant son schéma conteneur avec un nom qualifié.

La valeur de search_path doit être une liste de noms de schémas séparés par des virgules. Si un des éléments de la liste est la valeur spéciale $user, alors le schéma ayant le nom renvoyé par SESSION_USER est substitué, si un tel schéma existe (sinon $user est ignoré).

Le schéma du catalogue système, pg_catalog, est toujours recherché, qu'il soit ou non mentionné dans le chemin. S'il est mentionné, alors il sera cherché dans l'ordre spécifié. Si pg_catalog ne fait pas partie du chemin, alors il sera cherché avant tout élément du chemin.

De même, la recherche des schémas passe toujours par le schéma des tables temporaires, pg_temp_nnn, si ce dernier existe. Il est toujours possible de l'ajouter dans le chemin en utilisant l'alias pg_temp. S'il ne fait pas partie du chemin, la recherche commencera par lui (avant même pg_catalog). Néanmoins, seuls les noms de relation (table, vue, séquence, etc.) et de type de données sont recherchés dans le schéma temporaire. Aucune fonction et aucun opérateur n'y sera recherché.

Lorsque des objets sont créés sans spécifier un schéma cible particulier, ils sont placés dans le premier schéma listé dans le chemin de recherche. Une erreur est rapportée si le chemin de recherche est vide.

La valeur par défaut de ce paramètre est '$user, public' (où la deuxième partie sera ignorée s'il n'existe pas de schéma nommé public). Elle supporte l'utilisation partagée d'une base de données (où aucun utilisateur n'a de schémas privés et tous partagent l'utilisation de public), de schémas privés par utilisateur et une combinaison des deux. D'autres effets peuvent être obtenus en modifiant le chemin de recherche par défaut soit globalement soit par utilisateur.

La valeur réelle actuelle du chemin de recherche peut être examinée via la fonction SQL current_schemas(). Elle n'est pas identique à la valeur de search_path, car current_schemas() affiche comment la requête apparaissant dans search_path sera résolue.

Pour plus d'informations sur la gestion des schémas, voir la Section 5.8.

default_tablespace (string)

Cette variable spécifie le tablespace par défaut dans lequel créé les objets (tables et index) quand une commande CREATE ne spécifie par explicitement un tablespace.

La valeur est soit le nom de le tablespace soit une chaîne vide pour indiquer l'utilisation de le tablespace par défaut de la base de données en cours. Si la valeur ne correspond pas au nom d'une base de données existantes, PostgreSQL utilisera automatiquement le tablespace par défaut de la base de données en cours.

Pour plus d'informations sur les espaces logiques, voir la Section 18.6.

check_function_bodies (boolean)

Ce paramètre est habituellement à true. Lorsqu'il vaut false, il désactive la validation de la chaîne du corps de la fonction lors de CREATE FUNCTION. Désactiver la validation est quelque fois utile pour éviter des problèmes tels que les références avant lors de la restauration des définitions de fonctions à partir d'une sauvegarde.

default_transaction_isolation (string)

Chaque transaction SQL a un niveau d'isolation, qui peut être soit << read uncommitted >>, soit << read committed >>, soit << repeatable read >> soit << serializable >>. Ce paramètre contrôle le niveau d'isolation par défaut de chaque nouvelle transaction. Par défaut, << read committed >>.

Consultez Chapitre 12 et SET TRANSACTION pour plus d'informations.

default_transaction_read_only (boolean)

Une transaction SQL en lecture seule ne pourrait pas modifier les tables non temporaires. Ce paramètre contrôle le statut de lecture seule par défaut de chaque nouvelle transaction. La valeur par défaut est faux (lecture/écriture).

Consultez SET TRANSACTION pour plus d'informations.

statement_timeout (integer)

Annule toute instruction prenant plus que le nombre spécifié de millisecondes. Une valeur de zéro désactive le chronomètre et est la valeur par défaut.

16.4.8.2. Locale et formatage

datestyle (string)

Configure le format d'affichage pour les valeurs de type date et heure, ainsi que les règles d'interprétation des valeurs de saisie des dates ambiguës. Pour des raisons historiques, cette variable contient deux composants indépendants : la spécification du format en sortie (ISO, Postgres, SQL ou German) et la spécification en entrée/sortie pour l'ordre année/mois/jour (DMY, MDY ou YMD). Elles peuvent être configurées séparément ou ensemble. Les mots clés Euro et European sont un synonyme pour DMY ; les mots clés US, NonEuro et NonEuropean sont des synonymes pour MDY. Voir la Section 8.5 pour plus d'informations. La valeur par défaut est ISO, MDY.

timezone (string)

Configure le fuseau horaire pour l'affichage et l'interprétation de la date et de l'heure. Par défaut, vaut 'unknown', ce qui signifie qu'il utilise ce que l'environnement système spécifie comme fuseau horaire. Voir la Section 8.5 pour plus d'informations.

australian_timezones (boolean)

Si vrai, ACST, CST, EST et SAT sont interprétés comme des fuseaux horaires australiens plutôt que comme des fuseaux horaires d'Amérique Nord/Sud. Par défaut à faux.

extra_float_digits (integer)

Ce paramètre ajuste le nombre de chiffres affichés par les valeurs à virgule flottante, ceci incluant float4, float8 et les types de données géométriques. La valeur du paramètre est ajouté au nombre standard de chiffres (FLT_DIG ou DBL_DIG comme approprié). La valeur peut être initialisée à une valeur maximum de 2 pour inclure les chiffres partiellement significatifs ; c'est tout spécialement utile pour sauvegarder les données à virgule flottante qui ont besoin d'être restaurées exactement. Cette variable peut aussi être négative pour supprimer les chiffres non souhaités.

client_encoding (string)

Initialise le codage côté client (ensemble de caractères). Par défaut, utilise le codage de la base de données.

lc_messages (string)

Initialise la langue dans laquelle les messages sont affichés. Les valeurs acceptables sont dépendantes du système ; voir Section 20.1 pour plus d'informations. Si cette variable est initialisée en tant que chaîne vide (ce qui est la valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur.

Avec certains systèmes, cette catégorie de locale n'existe pas. Initialiser cette variable fonctionnera toujours mais n'aura aucun effet. De même, il existe une chance pour qu'aucun message traduit n'existe pour la langue sélectionnée. Dans ce cas, vous continuerez de voir les messages en anglais.

lc_monetary (string)

Initialise la locale à utiliser pour formater les montants de monnaie, par exemple avec la famille de fonctions to_char. Les valeurs acceptables dépendent du système ; voir la Section 20.1 pour plus d'informations. Si cette variable est une chaîne vide (la valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur.

lc_numeric (string)

Initialise la locale à utiliser pour formater les nombres, par exemple avec la famille de fonctions to_char. Les valeurs acceptables dépendent du système ; voir la Section 20.1 pour plus d'informations. Si cette variable est une chaîne vide (valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur.

lc_time (string)

Initialise la locale à utiliser pour formater les valeurs de date et d'heure (actuellement, ce paramétrage ne fait rien mais il le pourrait dans le futur). Les valeurs acceptables dépendent du système ; voir la Section 20.1 pour plus d'informations. Si cette variable est une chaîne vide (la valeur par défaut), alors la valeur est héritée de l'environnement système du serveur.

16.4.8.3. Autres valeurs par défaut

explain_pretty_print (boolean)

Détermine si EXPLAIN VERBOSE utilise le format indenté ou non pour l'affichage des arbres détaillés des requêtes. Activé par défaut.

dynamic_library_path (string)

Si un module chargeable dynamiquement a besoin d'être ouvert et que le nom de fichier spécifié dans la commande CREATE FUNCTION ou LOAD ne contient pas de répertoire (c'est-à-dire que le nom ne contient pas de slash), le système cherchera ce chemin pour le fichier requis.

La valeur pour dynamic_library_path doit être une liste de chemins absolus séparés par des virgules (ou des points virgules sous Windows). Si un élément de la liste commence avec la chaîne spéciale $libdir, le répertoire des bibliothèques internes du paquetage PostgreSQL est substitué à $libdir. C'est l'emplacement où sont installés les modules fournis par la distribution PostgreSQL standard (utilisez pg_config --pkglibdir pour connaître le nom de ce répertoire). Par exemple :

dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'

ou dans un environnement Windows :

dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'

La valeur par défaut de ce paramètre est '$libdir'. Si la valeur est une chaîne vide, la recherche automatique du chemin est désactivée.

Ce paramètre peut être modifié à l'exécution par les superutilisateurs mais un paramétrage réalisé de cette façon ne persistera que pendant la durée de la connexion du client, donc cette méthode devrait être réservée à des buts de développements. La façon recommandée pour initialiser ce paramètre est d'utiliser le fichier de configuration postgresql.conf.

16.4.9. Gestion des verrous

deadlock_timeout (integer)

Temps total, en millisecondes, d'attente d'un verrou avant de vérifier s'il s'agit d'une condition de verrous morts (deadlock condition). La vérification d'un verrou mort est assez lente, donc le serveur ne le fait pas à chaque fois qu'il attend pour un verrou. Nous supposons (de façon optimiste) que les verrous morts ne sont pas communs pour les applications de production et nous attendons simplement un verrou pendant un certain temps avant de lancer une recherche de blocage. Augmenter cette valeur réduit le temps perdu en recherche inutile de verrous morts mais ralentit la détection de vraies erreurs de verrous morts. La valeur par défaut est de 1000 (c'est-à-dire une par seconde), ce qui est probablement la plus petite valeur que vous pourriez vouloir en pratique. Sur un serveur déjà chargé, vous pouvez l'augmenter. Idéalement, ce paramétrage devrait dépasser le temps typique d'une transaction de façon à améliorer la probabilité qu'un verrou soit abandonné avant que le processus en attente ne décide de lancer une recherche de verrous morts.

max_locks_per_transaction (integer)

La table des verrous partagés a une taille basée sur la supposition que au moins max_locks_per_transaction * max_connections objets distincts seront nécessaires pour être verrouillés en même temps. (De coup, le nom de ce paramètre pourrait rendre confus : il n'y a pas de limite dur sur le nombre de verrous pris par une transaction, mais plutôt une valeur moyenne oui maximum.) Par défaut, 64, qui a prouvé son adéquation historiquement mais vous pourriez avoir besoin d'augmenter cette valeur si vous avez des clients qui touchent beaucoup de tables différentes dans une seule transaction. Cette option est initialisée au lancement du serveur uniquement.

16.4.10. Compatibilité de version et de plateforme

16.4.10.1. Précédentes versions de PostgreSQL

add_missing_from (boolean)

Si true, les tables qui sont référencées par une requête seront automatiquement ajoutées dans la clause FROM si elles n'y sont pas déjà présentes. La valeur par défaut est true pour des raisons de compatibilité avec les versions précédentes de PostgreSQL. Néanmoins, ce comportement n'appartient pas au standard SQL et beaucoup de personnes ne l'aiment pas car elle peut masquer les erreurs (comme référencer une table où vous devriez avoir référencé son alias). L'initialiser à false pour avoir un comportement en compatibilité avec le standard SQL permet de rejeter les références non listés dans la clause FROM.

backslash_quote (string)

Ceci contrôle si un guillemet peut être représenté par un \' dans une chaîne. Le moyen préféré, standard SQL, pour représenter un guillemet est de le doubler ('') mais, historiquement, PostgreSQL accepte aussi \'. Néanmoins, l'utilisation de \' ajoute des problèmes liés à la sécurité car certains codages d'ensembles de caractères des clients contiennent des caractères multi-octets dans lesquel le dernier octet est l'équivant ASCII numérique d'un \. Si le code côté client ne fait pas un échappement correct, alors une attaque par injection SQL est possible. Ce risque peut être annihilé en s'assurant que le serveur rejette les requêtes dans lesquelles apparait un guillemet à échapper avec un antislash. Les valeurs autorisées de backslash_quote sont on (autorise \' en permanence), off (rejette en permanence) et safe_encoding (l'autorise seulement si le codage du client n'autorise pas l'ASCII \ dans un caractère multioctet). safe_encoding est le paramétrage par défaut.

default_with_oids (boolean)

Elle contrôle si les commandes CREATE TABLE et CREATE TABLE AS incluent une colonne OID dans les tables nouvellement créées, si ni WITH OIDS ni WITHOUT OIDS ne sont spécifiées. Elle détermine aussi si les OID seront inclus dans les tables créés par SELECT INTO. Dans PostgreSQL 8.0.25, la valeur par défaut de default_with_oids est true. C'est aussi le comportement des versions précédentes de PostgreSQL. Néanmoins, supposer que les tables contiendront des OID par défaut n'est pas encouragé. Cette option aura probablement la valeur false par défaut dans une future version de PostgreSQL.

Pour faciliter la compatibilité avec les applications utilisant les OID, cette option devrait être activée. Pour faciliter la compatibilité avec les futures versions de PostgreSQL, cette option devrait être désactivée et les applications réclamant des OID sur certaines tables devraient spécifier explicitement WITH OIDS lors de la création de ces tables.

regex_flavor (string)
regex_flavor (string)

La << saveur >> des expressions rationnelles peut être advanced (avancée), extended (étendue) ou basic (basique). La valeur par défaut est advanced. Le paramétrage extended peut être utile pour une compatibilité ascendante exacte avec les versions précédant la 7.4 de PostgreSQL. Voir la Section 9.7.3.1 pour les détails.

sql_inheritance (boolean)

Ceci contrôle la sémantique de l'héritage, en particulier si les sous-tables sont incluses par les différentes commandes par défaut. Elles ne l'étaient pas dans les versions antérieures à la 7.1. Si vous avez besoin de l'ancien comportement, vous pouvez désactiver cette variable mais, à long terme, vous êtes encouragé à changer vos applications pour utiliser le mot clé ONLY qui exclut les sous-tables. Voir la Section 5.5 pour plus d'informations sur les héritages.

16.4.10.2. Compatibilité de la plateforme et du client

transform_null_equals (boolean)

Une fois activée, les expressions de la forme expr = NULL (ou NULL = expr) sont traitées comme expr IS NULL, c'est-à-dire qu'elles renvoient vrai si expr s'évalue par la valeur NULL, et faux sinon. Le bon comportement, compatible avec le standard SQL, de expr = NULL est de toujours renvoyer NULL (inconnu). Du coup, cette option est désactivée par défaut.

Néanmoins, les formulaires filtrés dans Microsoft Access génèrent des requêtes qui utilisent expr = NULL pour tester les valeurs NULL, donc si vous utilisez cette interface pour accéder à une base de données, vous souhaiterez activer cette option. Comme les expressions de la forme expr = NULL renvoient toujours la valeur NULL (en utilisant la bonne interprétation), elles ne sont pas très utiles et n'apparaissent pas souvent dans les applications normales, donc cette option a peu d'utilité en pratique. Mais les nouveaux utilisateurs confondent fréquemment la sémantique des expressions impliquant des valeurs NULL. Du coup, cette option n'est pas activée par défaut.

Notez que cette option affecte seulement la forme exacte = NULL, aucun autre opérateur de comparaison ou aucune autre expression qui sont équivalentes en terme de calcul à des expressions impliquant l'opérateur égal (telles que IN). Du coup, cette option n'est pas un correctif général pour une mauvaise programmation.

Référez-vous à la Section 9.2 pour des informations en relation.

16.4.11. Options préconfigurées

Les << paramètres >> suivant sont en lecture seule et sont déterminés lors de la compilation ou de l'installation de PostgreSQL. Ainsi, ils ont été exclus du fichier postgresql.conf d'exemple. Ces options rapportent différents aspects du comportement de PostgreSQL qui pourraient avoir un intérêt pour certaines applications, particulièrement pour les interfaces d'administration.

block_size (integer)

Affiche la taille d'un bloc disque. Elle est déterminée par la valeur de BLCKSZ à la construction du serveur. La valeur par défaut est de 8192 octets. La signification de quelques variables de configuration (comme shared_buffers) est influencée par block_size. Voir la Section 16.4.3 pour plus d'informations.

integer_datetimes (boolean)

Affiche si PostgreSQL a été construit avec le support des dates et heures sur des entiers de 64 bits. Il est configuré en utilisant --enable-integer-datetimes au moment de la construction de PostgreSQL. La valeur par défaut est off.

lc_collate (string)

Affiche la locale utilisée pour le tri des données de type texte. Voir la Section 20.1 pour plus d'informations. La valeur est déterminée lors de l'initialisation du groupe de bases de données.

lc_ctype (string)

Affiche la locale déterminant les classifications de caractères. Voir la Section 20.1 pour plus d'informations. La valeur est déterminée au moment de l'initialisation du groupe de bases de données. D'habitude, elle sera identique à lc_collate mais, pour des applications particulières, elle pourrait être configurée différemment.

max_function_args (integer)

Affiche le nombre maximum d'arguments des fonctions. Ce nombre est déterminé par la valeur de FUNC_MAX_ARGS lors de la construction du serveur. La valeur par défaut est de 32.

max_identifier_length (integer)

Affiche la longueur maximum d'un identifiant. Elle est déterminée comme valant NAMEDATALEN moins un lors de la construction du serveur. La valeur par défaut de NAMEDATALEN est 64 ; du coup, la valeur par défaut de max_identifier_length est 63.

max_index_keys (integer)

Affiche le nombre maximum de clés d'index. Ce nombre est déterminé par la valeur de INDEX_MAX_KEYS lors de la construction du serveur. La valeur par défaut est 32.

server_encoding (string)

Affiche le codage de la base de données (ensemble de caractères). Il est déterminé lors de la création de la base de données. Habituellement, les clients sont seulement concernés par la valeur de client_encoding.

server_version (string)

Affiche le numéro de version du serveur. Il est déterminé par la valeur de PG_VERSION lors de la construction du serveur.

16.4.12. Options personnalisées

Cette fonctionnalité a été conçue pour permettre l'ajout d'options habituellement inconnues de PostgreSQL car ajoutées par des modules supplémentaires (comme les langages de procédures). Ceci autorise les modules à être configuré de la façon standard.

custom_variable_classes (string)

Cette variable spécifie un ou plusieurs noms de classe à utiliser par des variables personnalisées, de la forme d'une liste séparée par des virgules. Une variable personnalisée est une variable habituellement inconnue de PostgreSQL lui-même mais utilisée par certains modules supplémentaires. Ces variables doivent avoir des noms consistant en un nom de classe, un point et un nom de variable. custom_variable_classes spécifie tous les noms de classe utilisés dans une installation particulière. Cette option est seulement disponible au lancement du serveur ou dans le fichier de configuration postgresql.conf.

La difficulté avec la configuration de variables personnalisées dans postgresql.conf est que le fichier doit être lu avant que les modules supplémentaires ne soient chargés et, du coup, les variables seraient habituellement rejetées comme étant inconnues. Lorsque custom_variable_classes est initialisé, le serveur acceptera les définitions de variables arbitraires à l'intérieur de chaque classe spécifiée. Ces variables seront traitées comme des emplacements vides et n'auront aucune fonction tant que le module qui les définit n'est pas chargé. Quand un module d'une classe spécifique est chargé, il ajoute les bonnes définitions de variables pour son nom de classe, convertit les valeurs des emplacements suivant les définitions et émet des messages d'avertissement pour tout emplacement restant dans sa classe (qui seraient à priori des noms de variables mal saisis).

Voici un exemple de ce que pourrait contenir postgresql.conf en utilisant des variables personnalisées :

custom_variable_classes = 'plr,pljava'
plr.path = '/usr/lib/R'
pljava.foo = 1
plruby.bar = true        # generates error, unknown class name

16.4.13. Options pour les développeurs

Les options suivantes ont pour but de travailler sur les sources de PostgreSQL et, dans certains cas, d'assister à une récupération sur des bases de données sévèrement endommagées. Il n'y a aucune raison pour les utiliser dans la configuration d'un système de production. En tant que tel, elles ont été exclues du fichier d'exemple de postgresql.conf. Notez qu'un certain nombre d'entre elles requièrent des options de compilation spéciales pour fonctionner.

debug_assertions (boolean)

Active différentes vérifications des affectations. C'est une aide au débogage. Si vous expérimentez des problèmes étranges ou des arrêts brutaux, vous pouvez l'activer car cette option pourrait exposer des erreurs de programmation. Pour utiliser cette option, la macro USE_ASSERT_CHECKING doit être définie lors de la construction de PostgreSQL (ceci s'accomplit par l'option --enable-cassert de configure). Notez que la valeur de debug_assertions est par défaut active si PostgreSQL a été construit après ajout de l'option ci-dessus.

debug_shared_buffers (integer)

Nombre de secondes entre les rapports des tampons freelist. Si plus grand que zéro, émet des statistiques freelist sur le journal toutes les debug_shared_buffers secondes. Zéro (par défaut) désactive les rapports.

pre_auth_delay (integer)

Si différent de zéro, un délai de ce nombre de secondes arrive juste après qu'un nouveau processus ne soit créé, avant le processus d'authentification. Ceci a pour but de donner une opportunité d'attacher un débogueur au processus serveur pour tracer les mauvais comportements pendant l'authentification.

trace_notify (boolean)

Génère un grand nombre de sorties de débogage pour les commandes LISTEN et NOTIFY. client_min_messages ou log_min_messages doivent être DEBUG1 ou plus bas pour envoyer cette sortie sur les traces client ou serveur, respectivement.

trace_locks (boolean)
trace_lwlocks (boolean)
trace_userlocks (boolean)
trace_lock_oidmin (boolean)
trace_lock_table (boolean)
debug_deadlocks (boolean)
log_btree_build_stats (boolean)

Différentes autres options de trace et de débogage.

wal_debug (boolean)

Si true, émet une sortie de débogage relative aux WAL. Cette option est seulement disponible si la macro WAL_DEBUG était définie au moment de la compilation de PostgreSQL.

zero_damaged_pages (boolean)

La détection d'une en-tête de page endommagée cause généralement le rapport d'une erreur par PostgreSQL, l'annulation de la commande courante. Initialiser zero_damaged_pages à vrai fait que le système rapporte à la place un avertissement, supprime la page endommagée et continue son traitement. Ce comportement détruira les données, nommément toutes les lignes de la page endommagée. Mais cela vous permettra de passer l'erreur et de récupérer les lignes des pages non endommagées qui pourraient être présentes dans la table. Donc, c'est utile pour récupérer les données si la corruption est dûe à une erreur matérielle ou logicielle. Vous ne devriez généralement pas configurer cette option à vrai sauf si vous abandonnez l'espoir de récupérer les données des pages endommagées d'une table. Le paramétrage par défaut est désactivé, et ne peut être modifié que par un superutilisateur.

16.4.14. Options courtes

Pour le côté pratique, voici les options sur une lettre en ligne de commande disponibles pour certains paramètres. Elles sont décrites dans le Tableau 16-1.

Tableau 16-1. Clés des options courtes

Option courteÉquivalent
-B xshared_buffers = x
-d xlog_min_messages = DEBUGx
-Ffsync = off
-h xlisten_addresses = x
-ilisten_addresses = '*'
-k xunix_socket_directory = x
-lssl = on
-N xmax_connections = x
-p xport = x
-fi, -fh, -fm, -fn, -fs, -ft[a] enable_indexscan=off, enable_hashjoin=off, enable_mergejoin=off, enable_nestloop=off, enable_seqscan=off, enable_tidscan=off
-s[a]log_statement_stats = on
-S x[a] work_mem = x
-tpa, -tpl, -te[a]log_parser_stats=on, log_planner_stats=on, log_executor_stats=on
Remarques :
a. Pour des raisons historiques, ces options doivent êtres passées au processus serveur individuel via l'option -o de postmaster, par exemple,

$ postmaster -o '-S 1024 -s'

ou via PGOPTIONS du côté client, comme expliqué ci-dessous.