18. Configuration du serveur

Tous les noms de paramètres sont insensibles à la casse. Chaque paramètre prend une valeur d'un de ces cinq types : booléen, entier, nombre à virgule flottante, chaîne de caractères ou énumération. Les unités par défaut peuvent être récupérées en référençant pg_settings.unit. Les valeurs booléennes peuvent être on, off, true, false, yes, no, 1, 0 ou tout préfixe non ambigü de celles-ci (toutes ces écritures sont insensibles à la casse).

Certains paramètres indiquent une valeur de taille mémoire ou de durée. Ils ont chacun une unité implicite, soit Ko, soit blocs (typiquement 8 Ko), soit millisecondes, soit secondes, soit minutes. Les unités par défaut peuvent être obtenues en interrogeant pg_settings.unit. Pour simplifier la saisie, une unité différente peut être indiquée de façon explicite. Les unités mémoire valides sont kB (kilo-octets), MB (Méga-octets) et GB (Giga-octets) ; les unités de temps valides sont ms (millisecondes), s (secondes), min (minutes), h (heures), et d (jours). Les unités de mémoire sont des multiples de 1024, pas de 1000.

Les paramètres de type « enum » sont spécifiés de la même façon que les paramètres de type chaîne, mais sont restreints à un jeu limité de valeurs. Les valeurs autorisées peuvent être obtenues de pg_settings.enumvals. Les paramètres enum sont insensibles à la casse.

Une façon d'initialiser ces paramètres est d'éditer le fichier postgresql.conf qui est normalement placé dans le répertoire des données (une copie par défaut est installé ici quand le répertoire des données est initialisé). Un exemple de contenu peut être :

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

Un paramètre est indiqué par ligne. Le signe égal entre le nom et la valeur est optionnel. Les espaces n'ont pas de signification et les lignes vides sont ignorées. Les symboles dièse (#) désignent le reste de la ligne comme un commentaire. Les valeurs des paramètres qui ne sont pas des identificateurs simples ou des nombres doivent être placées entre guillemets simples. Pour intégrer un guillemet simple dans la valeur d'un paramètre, on écrit soit deux guillemets (c'est la méthode préférée) soit un antislash suivi du guillemet.

Il existe aussi une directive include_if_exists, qui agit de la même façon que la directive include, sauf si le fichier n'existe pas ou ne peut pas être lu. La directive include traitera cela comme une erreur, mais la directive include_if_exists tracera cet événement et continuera le traitement du fichier de configuration.

Le fichier de configuration est relu à chaque fois que le processus serveur principal reçoit un signal SIGHUP. Ceci se fait facilement en exécutant pg_ctl reload à partir de la ligne de commande ou en appelant la fonction SQL pg_reload_conf(). Le processus serveur principal 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. Il est également possible d'envoyer le signal directement à un seul processus serveur. Quelques paramètres ne peuvent être initialisés qu'au lancement du serveur ; tout changement de leur valeur dans le fichier de configuration est ignoré jusqu'au prochain démarrage du serveur. Les configuration invalides de paramètres seront ignorées, mais tracées, lors du traitement du SIGHUP.

Une autre façon de configurer ces paramètres est de les passer comme option de la commande postgres :

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

Les options de la ligne de commande surchargent le paramétrage effectué dans le fichier postgresql.conf. Ce qui signifie que la valeur d'un paramètre passé en ligne de commande ne peut plus être modifiée et rechargée à la volée à l'aide du fichier postgresql.conf. C'est pourquoi, bien que la méthode de la ligne de commande paraisse pratique, elle peut coûter en flexibilité par la suite.

Il est parfois utile de donner une option en ligne de commande pour une session particulière unique. La variable d'environnement PGOPTIONS est utilisée côté client à ce propos :

env PGOPTIONS='-c geqo=off' psql

(Cela fonctionne pour toute application client fondée sur libpq, et non pas seulement pour psql.) Cela ne fonctionne pas pour les paramètres fixés au démarrage du serveur ou qui doivent être précisés dans postgresql.conf.

De plus, il est possible d'affecter un ensemble de paramètres à un utilisateur ou à une base de données. Quand une session est lancée, les paramètres par défaut de l'utilisateur et de la base de données impliqués sont chargés. Les commandes ALTER ROLE(7) et ALTER DATABASE(7) sont respectivement utilisées pour configurer ces paramètres. Les paramètres par base de données surchargent ceux passés sur la ligne de commande de postgres ou du fichier de configuration et sont à leur tour surchargés par ceux de l'utilisateur ; les deux sont surchargés par les paramètres de session.

Quelques paramètres peuvent être modifiés dans les sessions SQL individuelles avec la commande SET(7), 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 : s'ils contrôlent un comportement qui ne peut pas être modifié sans relancer le serveur PostgreSQL™, par exemple. De,plus, certaines paramètres requièrent l'attribut superutilisateur pour être modifié avec les instructions SET ou ALTER.

La commande SHOW(7) permet d'inspecter les valeurs courantes de tous les paramètres.

La table virtuelle pg_settings autorise aussi l'affichage et la mise à jour de paramètres de session à l'exécution ; voir Section 47.66, « pg_settings » pour les détails et une description des différents types de variable et de comment ils peuvent être changés. pg_settings est équivalente à SHOW et SET mais peut être plus facile à utiliser parce qu'elle peut être jointe avec d'autres tables et que ses lignes peuvent être sélectionnées en utilisant des conditions personnalisées. Elle contient aussi davantage d'informations sur chaque paramètre que ce qui est disponible avec SHOW.

En plus des paramètres, le fichier postgresql.conf peut contenir des directives d'inclusion, qui précisent les autres fichiers à lire et à traiter comme s'ils étaient insérés dans le fichier de configuration à cet emplacement. Cette fonctionnalité permet de diviser un fichier de configuration en plusieurs parties séparées. Les directives d'inclusion ressemblent à :

include 'nom_fichier'

Si le nom du fichier n'est pas un chemin absolu, il est considéré comme relatif au répertoire contenant le fichier de configuration de référence. Les inclusions peuvent être imbriquées.

Il existe aussi une directive include_if_exists qui agit de la même façon que la directive include sauf si le fichier référencé n'existe pas ou ne peut pas être lu. La directive include considère ces états comme une condition d'erreur mais include_if_exists ne fait que tracer un message et continue le traitement du fichier de configuration de référence.

Le fichier postgresql.conf peut aussi contenir include_dir directives, qui précise un répertoire entier de fichiers de configuration à inclure. Il s'utilise de la même façon :

 include_dir 'répertoire'
 

Les noms de répertoires relatifs suivent la même règle que les directives d'inclusion de fichiers : ils sont relatifs au répertoire contenant le fichier de configuration référençant. Dans ce répertoire, ne seront pris en compte que les fichiers dont le nom se termine avec le suffixe .conf. Les noms de fichier qui commencent avec le caractère . seront aussi exclus pour prévenir les erreurs car ils sont cachés sur certaines platformes. Les différents fichiers d'un même répertoire sont traités dans l'ordre alphabétique de leur nom. Les noms de fichiers sont triés suivant les règles de la locale C, c'est-à-dire les nombres avant les lettres, et les majuscules avant les minuscules.

Les fichiers ou répertoires inclus peuvent être utilisés pour séparer logiquement les portions séparées de la configuration de la base, plutôt que d'avoir un énorme fichier postgresql.conf. Pensez à une société qui a deux serveurs de bases de données, chacun disposant d'une quantité de mémoire différente. Il y a de fortes chances que certains éléments de la configuration seront partagés, par exemple la configuration des traces. Par contre, les paramètres relatifs à la mémoire sur le serveur varieront entre les deux. Et il pourrait y avoir aussi des personnalisations spécifiques à chaque serveur. Une façon de gérer cette situation est de casser les modifications personnalisées de configuration en trois fichiers. Il suffit d'ajouter ceci en fin du fichier postgresql.conf pour les inclure :

 include 'commun.conf'
 include 'memoire.conf'
 include 'serveur.conf'
 

Tous les systèmes auraient le même commun.conf. Chaque serveur avec une quantité particulière de mémoire pourrait partager le même memory.conf. Vous pourriez en avoir un pour tous les serveurs disposant de 8 Go de RAM, un autre pour ceux ayant 16 Go. Enfin, serveur.conf pourrait avoir les configurations réellement spécifiques à un serveur.

Une autre possibilité revient à créer un répertoire de fichiers de configuration et de placer les fichiers dans ce répertoire. Par exemple, un répertoire conf.d pourrait être référencé à la fin du postgresql.conf :

 include_dir 'conf.d'
 

Ensuite, vous pourriez renommer les fichiers dans le répertoire conf.d de cette façon :

 00commun.conf
 01memoire.conf
 02serveur.conf
 

Ceci donne un ordre clair pour le chargement de ces fichiers. Ceci est important car seule la dernière configuration rencontrée pour un même paramètre est utilisée quand le serveur lit la configuration. Par exemple, un paramètre configuré conf.d/02server.conf surchargerait la configuration du même paramètre dans conf.d/01memory.conf.

Vous pourriez utiliser cette approche par répertoire de configuration pour nommer les fichiers de façon plus claire :

 00commun.conf
 01memoire-8Go.conf
 02serveur-truc.conf
 

Ce type d'arrangement donne un nom unique pour chaque variation du fichier de configuration. Ceci peut aider à éliminer l'ambiguïté quand plusieurs serveurs ont leur configuration stockée au même endroit, par exemple dans un dépôt de contrôle de version. (Stocker les fichiers de configuration de la base avec un outil de contrôle de version est une autre bonne pratique à considérer.)