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 des ces quatre types : booléen, entier, nombre à virgule flottante et chaîne de caractères. Les valeurs booléennes peuvent valoir 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 du répertoire data. (Un fichier par défaut y est installé.) Un exemple de ce que ce fichier peut contenir pourrait ressembler à ceci :

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

Un 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 partout. Les valeurs des paramètres qui ne sont pas des identifiants simples ou des nombres devraient ê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.

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 syslog=2

Les options de la ligne de commande surchargent tout paramétrage en conflit dans postgresql.conf.

Occasionnellement, il est aussi 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é (par exemple pour le numéro de port).

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 DATABASE et ALTER USER, 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. Les superutilisateurs sont autorisés à utiliser SET avec plus de paramètres que les 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 43.34) 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. Connexions et authentification

16.4.1.1. Paramétrages de connexion

tcpip_socket (boolean)

S'il est vrai, alors le serveur acceptera des connexions TCP/IP. Sinon seules les connexions par socket de domaine Unix sont acceptées. Cette option est désactivée par défaut et ne peut être activée qu'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 d'<< emplacements de connexion >> réservés aux superutilisateurs PostgreSQL. Au plus max_connections connexions peuvent être activées simultanément. À chaque fois que le nombre de connexions concurrentes actives arrive 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.

port (integer)

Le port TCP où le serveur écoute ; 5432 par défaut. Cette option est seulement initialisable au lancement du serveur.

unix_socket_directory (string)

Spécifie le répertoire de la socket de domaine Unix sur lequel le serveur attend les connexions des applications clientes. Par défaut, il s'agit de /tmp mais cela est modifiable à la construction.

unix_socket_group (string)

Initialise 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 ce type de socket. Par défaut, la chaîne est vide et utilise le groupe par défaut de l'utilisateur. Cette option est configurable uniquement au lancement du serveur.

unix_socket_permissions (integer)

Initialise les droits d'accès au socket de domaine Unix. Les sockets de domaine Unix utilisent l'ensemble habituel des droits du système de fichiers Unix. La valeur de l'option est attendue dans sa spécification en mode numérique, acceptée par les appels système chmod et umask. (Pour utiliser le format octal personnalisé, le 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 (seulement l'utilisateur et le groupe, voir aussi sous unix_socket_group) et 0700 (seulement l'utilisateur). (Notez que pour un socket de domaine Unix, seuls les droits d'écriture ont une signification et il n'y a aucune raison à ajouter ou supprimer 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 Chapitre 19.

Cette option est seulement configurable au lancement du serveur.

virtual_host (string)

Spécifie le nom d'hôte ou l'adresse IP sur lequel le serveur est en attente de connexions d'applications clients. Par défaut, il écoute sur toutes les adresses configurées (incluant localhost).

rendezvous_name (string)

Spécifie le nom de << broadcast >> de RendezVous. Par défaut, le nom de l'ordinateur est utilisé, spécifié comme ''.

16.4.1.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.7 avant d'utiliser ceci. Désactivée par défaut.

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)

Quand un mot de passe est spécifié dans CREATE USER ou ALTER USER sans écrire soit ENCRYPTED soit UNENCRYPTED, cette option détermine si le mot de passe doit être crypté. Activé par défaut (donc cryptage du mot de passe).

krb_server_keyfile (string)

Initialise l'emplacement du fichier clé du serveur Kerberos. Voir Section 19.2.3 pour plus de 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@nombase. 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.2. Consomnation de ressources

16.4.2.1. Memoire

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 différente valeur 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.

sort_mem (integer)

Spécifie la mémoire utilisée par les opérations internes de tri et par les tables de hachage avant de basculer sur des fichiers temporaires sur disque. La valeur est spécifiée en Ko et correspond par défaut à 1024 Ko (soit 1 Mo). Notez que pour une requête complexes, plusieurs tris ou opérations de hachage pourraient être lancés en parallèle ; chacun sera autorisé à utiliser autant de mémoires que cette valeur spécifie avant de commener à placer les données dans des fichiers temporaires. De plus, plusieurs sessions en cours d'exécution pourraient effectuer des opérations de tri en même temps. Donc, la mémoire totale utilisée pourrait être de plusieurs fois la valeur de sort_mem. Les opérations de tri sont utilisées par ORDER BY, les jointures merge et CREATE INDEX. Les tables de hachage sont utilisées dans les jointures hachées, les agrégats à base de hachage et les traitements de sous-requêtes IN basés sur des hachages. Comme CREATE INDEX est utilisé lors de la restauration d'une base de données, augmenter sort_mem avant de faire une grosse opération de restauration peut améliorer les performances.

vacuum_mem (integer)

Spécifie la mémoire maximum utilisée par VACUUM pour garder trace des lignes à réclamer. La valeur est spécifiée en Ko et vaut par défaut 8192 Ko. Une configuration plus importante pourrait améliorer la rapidité du vacuum sur les grosses tables qui ont beaucoup de lignes supprimées.

16.4.2.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.2.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 malib ou malib_init 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 augmente même si le processus n'utilise pas la bibliothèque.

16.4.3. Write Ahead Log

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

16.4.3.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. (Les arrêts brutaux du serveur de bases de données ne sont pas eux-même en relation avec ceci.)

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.

À 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), 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. 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 en mémoire partagée pour les traces WAL. La valeur par défaut est 8. Cette option n'est configurable qu'au lancement du serveur.

16.4.3.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 traces du serveur si les points de vérification causés par le remplissage des fichiers de segment arrivent plus fréquemment que ce nombre de secondes. La valeur par défaut est de 30 secondes. Une valeur nulle désactive cet avertissement.

commit_delay (integer)

Délai entre l'écriture de 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 autorise la validation de plusieurs transactions avec un seul appel système fsync() si la charge système est assez haute pour que des transactions supplémentaires soient disponibles à la validation dans l'intervalle donné. Mais le délai est predu si aucune autre transaction n'est prête à la validation. Du coup, le délai est réalisé si au moins commit_siblings autres transactions sont actives à l'instant où un processus serveur a écrit son enregistrement de validation. La valeur par défaut est de zéro (pas de délai).

commit_siblings (integer)

Nombre minimum de transactions ouvertes concurrentes réclamées avant d'exécuter le délai commit_delay. Une valeur plus importante rend plus probable qu'au moins une autre transaction sera prête à la validation lors du délai. La valeur par défaut est de cinq.

16.4.4. Planification des requêtes

16.4.4.1. Configuration de la méthode du planificateur

Note : 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'autres façons d'améliorer la qualité des plans choisis par l'optimiseur incluent la configuration de Constantes de coût du planificateur, lancer ANALYZE plus fréquemment et d'accroître le nombre de statistiques récoltées pour une colonne particulière 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. C'est utilisé pour déboguer le planificateur de requêtes.

enable_hashjoin (boolean)

Active ou désactive l'utilisation des jointures hachées par le planificateur. Actif par défaut. C'est utilisé pour déboguer le planificateur de requêtes.

enable_indexscan (boolean)

Active ou désactive l'utilisation des parcours d'index par le planificateur. Actif par défaut. C'est utilisé pour déboguer le planificateur de requêtes.

enable_mergejoin (boolean)

Active ou désactive l'utilisation des jointures de fusion par le planificateur. Actif par défaut. C'est utilisé pour déboguer le planificateur de requêtes.

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. C'est utilisé pour déboguer le planificateur de requêtes.

enable_seqscan (boolean)

Active ou déactive 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. C'est utilisé pour déboguer le planificateur de requêtes.

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. C'est utilisé pour déboguer le planificateur de requêtes.

enable_tidscan (boolean)

Active ou désactive l'utilisation des parcours de TID par le planificateur. Actif par défaut. C'est utilisé pour déboguer le planificateur de requêtes.

16.4.4.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)

Initialise la supposition du planificateur sur la taille réelle du cache disque (c'est-à-dire la portion du cache disque du noyau qui sera utilisée pour les fichiers de données de PostgreSQL). C'est mesuré en pages disque, qui font normalement 8192 octets chacun. La valeur par défaut est de 1000.

random_page_cost (floating point)

Initialise l'estimation du coût du planificateur de requêtes 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 de requête 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 de requête 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.4.3. Optimiseur génétique de requêtes

geqo (boolean)

Active ou désactive l'optimisation génétique des requêtes, algorithme qui tente de faire une planification des requêtes sans recherche exhaustive. Actif par défaut. Voir les autres paramétrages geqo_.

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'un construction JOIN externe compte seulement comme un élément du FROM.) La valeur par défaut est de 11. Pour des requêtes simples, il est généralement mieux 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)
geqo_generations (integer)
geqo_pool_size (integer)
geqo_selection_bias (floating point)

Différents paramètres pour l'algorithme d'optimisation génétique des requêtes : la taille de la queue est le nombre d'individus dans une population. Les valeurs valides sont comprises entre 128 et 1024. Si elle est initialisée à 0 (valeur par défaut), une valeur de 2^(QS+1), où QS est le nombre d'éléments dans la clause FROM, est prise. L'effort est utilisé pour calculer une valeur par défaut pour les générations. Les valeurs valides sont entre 1 et 80, 40 étant la valeur par défaut. Les générations spécifient le nombre d'itérations dans l'algorithme. Le nombre doit être un entier positif. Si 0 est spécifié, alors Effort * Log2(PoolSize) est utilisé. Le temps d'exécution de l'algorithme est grossièrement proportionnel à la somme de la taille de la queur et aux générations. Le biais de sélection est la pression sélective à l'intérieur de la population. Les valeurs peuvent aller de 1,50 à 2,00 ; la dernière étant la valeur par défaut.

16.4.4.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.

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 va aplatir les constructions JOIN internes explicites dans des listes d'élements pour la clause FROM lorsqu'il y a moins que ce nombre d'éléments. Habituellement, c'est identique à from_collapse_limit. Le configurer à 1 empêche tout aplatissement des JOIN internes, permettant l'utilisation de la syntaxe JOIN explicite pour contrôler l'ordre de jointure. Les valeurs intermédiaires sont utiles pour étabir un équilibre entre le temps de planification et la qualité du plan.

16.4.5. Rapports d'erreur et traces

16.4.5.1. Syslog

syslog (integer)

PostgreSQL permet l'utilisation de syslog pour ses traces. Si cette option est initialisée à 1, les messages vont à la fois dans syslog et sur la sortie standard. Un paramétrage de 2 envoie la sortie uniquement dans syslog. (Quelques messages iront toujours sur la sortie standard ou la sortie des erreurs.) Cette option est par défaut à 0, signifiant que syslog est désactivée. Cette option doit être initialisée au lancement du serveur.

syslog_facility (string)

Cette option détermine le niveau (<< facility >>) que syslog doit utiliser pour tracer avec 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 syslog de votre serveur.

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.

16.4.5.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 accroître cette option.

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, chacun ajoutant plus de champs aux messages affichés.

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 accroître cette option.

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 option. 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 augmenter cette option ou la configurer à -1 si cette option a été initialisée par l'administrateur.

silent_mode (boolean)

Exécute le serveur en mode silencieux. Si cette option est donnée, le serveur sera lancé automatiquement en tâche de fond et tous les terminaux de contrôle seront dissociés. Du coup, aucun message ne sera écrit sur la sortie standard ou sur la sortie des erreurs (effet identique à l'option -S de postmaster). Sauf si les traces syslog sont activées, l'utilisation de cette option n'est pas encouragée car elle rend impossible la visualisation des 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 transaction actuelle.

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.5.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 à être envoyées au client ou dans les traces du serveur. 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 envoyer la sortie vers le client ou les traces du serveur. 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_duration (boolean)

Trace la durée de toute instruction exécutée. Pour utiliser cette option, activez log_statement et log_pid de façon à pouvoir lier l'instruction à la durée en utilisant l'identifiant du processus. Désactivée par défaut, seuls les superutilisateurs peuvent désactiver cette option si elle a été activée par l'administrateur.

log_pid (boolean)

Préfixe chaque message dans le journal des traces du serveur avec l'identifiant de processus du serveur. C'est utile pour associer les messages aux connexions. Désactivé par défaut, ce paramètre n'affecte pas les messages tracés via syslog, qui contient toujours l'identifiant du processus.

log_statement (boolean)

Trace toutes les instructions SQL. Cette option est désactivée par défaut. Seuls les superutilisateurs peuvent désactiver cette option si elle a été activée par l'administrateur.

log_timestamp (boolean)

Préfixe chaque message du journal des traces avec une indication de la date et de l'heure. Désactivée par défaut.

log_hostname (boolean)

Par défaut, les traces des connexions n'affichent que l'adresse IP de l'hôte se connectant. Si vous souhaitez qu'il affiche le nom de l'hôte, vous pouvez activer cette option mais suivant votre configuration de résolution de nom d'hôte, cela pourrait imposer une pénalité des performances non négligeable. Cette option est seulement configurable au lancement du serveur.

log_source_port (boolean)

Affiche le numéro de port de l'hôte connecté dans les messages de trace des connexions. Vous pouvez traver le numéro de port pour trouver l'utilisateur connecté. En dehors de cela, cette option est pratiquement inutile et est donc désactivée par défaut. Cette option est seulement configurable au lancement du serveur.

16.4.6. Statistiques d'exécution

16.4.6.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 outi brut de profilage. Toutes ces options sont désactivées par défaut. Seuls les superutilisateurs peuvent les désactiver si elles ont tout d'abord été activées par l'administrateur.

16.4.6.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)
stats_row_level (boolean)

Ceci active la récupération de statistiques sur l'activité du serveur au niveau bloc et ligne, respectivement. Ces options sont désactivées par défaut. Les données sont accessibles via les familles de vues système pg_stat et pg_statio ; référez-vous à Chapitre 23 pour plus d'informations.

stats_reset_on_server_start (boolean)

En cas d'activation, les statistiques récupérées sont supprimées à chaque redémarrage du serveur. Sinon, les statistiques sont accumulées avec les redémarrage du serveur. Par défaut, cette option est activée et peut seulement être configurée au lancement du serveur.

16.4.7. Valeurs par défaut des connexions client

16.4.7.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.

check_function_bodies (boolean)

Ce paramètre est normalement vrai. Lorsqu'il est initialisé à faux, il désactive la validation de la chaîne du corps d'une fonction dans CREATE FUNCTION. Désactiver la validation est quelque fois utile pour éviter des problèmes tels que des références lors de la restauration de définition de fonctions à partir d'une sauvegarde.

default_transaction_isolation (string)

Chaque transaction SQL a un niveau d'isolation, qui peut être soit << read committed >> soit << serializable >>. Ce paramètre contrôle le niveau d'isolation par défaut de chaque nouvelle transaction. La valeur par défaut est << 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.7.2. Locale et formatage

datestyle (string)

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

timezone (string)

Initialise le fuseau horaire pour l'affichage et l'interprétation de l'heure. La valeur par défaut utilise ce que spécifie l'environnement système comme fuseau horaire. Voir Section 8.5 pour plus d'informations.

australian_timezones (boolean)

Si vrai, ACST, CST, EST et SAT sont interprétés commes 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 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.7.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 spécifié ne spécifie par un répertoire (c'est-à-dire que le nom ne comporte pas de slash), le système cherchera le fichier dans ce chemin. (Le nom utilisé est le nom spécifié dans la commande CREATE FUNCTION ou LOAD.)

La valeur de dynamic_library_path doit être une liste de noms absolus de répertoire séparés par des virgules. Si un nom de répertoire commence avec la valeur spéciale $libdir, le répertoire des bibliothèques du paquet PostgreSQL est substitué à sa place. C'est ici que sont installés les modules fournis par la distribution PostgreSQL. (Utilisez pg_config --pkglibdir pour afficher le nom de ce répertoire.) Par exemple :

dynamic_library_path = '/usr/local/lib/postgresql:/home/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.

max_expr_depth (integer)

Initialise la profondeur d'imbrication maximale de l'expression. La valeur par défaut de 10000 est assez haute pour toute requête normale mais vous pouvez l'augmenter si vous le souhaitez. (Mais si vous l'augmentez de trop, vous courrez le risque d'un arrêt brutal du serveur à cause d'un dépassement de pile.)

16.4.8. 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 attent 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. 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.9. Compatibilité de version et de plateforme

16.4.9.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énamoins, ce comportement n'appartient pas au standard SQL et beaucoup de personnes ne l'aiment pas car elle peut masquer les erreurs. 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.

regex_flavor (string)

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

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.9.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 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 l'opérateur littéral =, 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.10. 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.

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_debogue (integer)

Si différent de zéro, active la sortie de débogage relative aux WAL.

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 transaction 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.11. 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 xvirtual_host = x
-itcpip_socket = on
-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] sort_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.