Documentation PostgreSQL 14.22 » Administration du serveur » Configuration du serveur » Valeurs par défaut des connexions client

Précédent | Niveau supérieur | Suivant
20.10. Nettoyage (`vacuum`) automatique | Sommaire | 20.12. Gestion des verrous

## 20.11. Valeurs par défaut des connexions client

### 20.11.1. Comportement des instructions

`client_min_messages` (`enum`)

  Contrôle les niveaux de message envoyés au client. Les valeurs valides sont `DEBUG5`, `DEBUG4`, `DEBUG3`, `DEBUG2`, `DEBUG1`, `LOG`, `NOTICE`, `WARNING` et `ERROR`. Chaque niveau inclut tous les niveaux qui le suivent. Plus on progresse dans la liste, plus le nombre de messages envoyés est faible. `NOTICE` est la valeur par défaut. `LOG` a ici une portée différente de celle de `log_min_messages`.

  Les messages de niveau `INFO` sont toujours envoyés au client.

`search_path` (`string`)

  Cette variable précise l'ordre dans lequel les schémas sont parcourus lorsqu'un objet (table, type de données, fonction, etc.) est référencé par un simple nom sans précision du schéma. Lorsque des objets de noms identiques existent dans plusieurs schémas, c'est le premier trouvé dans le chemin de recherche qui est utilisé. Il ne peut être fait référence à un objet qui ne fait partie d'aucun des schémas indiqués dans le chemin de recherche qu'en précisant son schéma conteneur avec un nom qualifié (avec un point).

  `search_path` doit contenir une liste de noms de schémas séparés par des virgules. Tout nom qui ne correspond pas à un schéma existant ou qui correspond à un schéma pour lequel l'utilisateur n'a pas le droit `USAGE`, est ignoré silencieusement.

  Si un des éléments de la liste est le nom spécial `$user`, alors le schéma dont le nom correspond à la valeur retournée par `CURRENT_USER` est substitué, s'il existe et que l'utilisateur ait le droit `USAGE` sur ce schéma (sinon `$user` est ignoré).

  Le schéma du catalogue système, `pg_catalog`, est toujours parcouru, qu'il soit ou non mentionné dans le chemin. Mentionné, il est alors parcouru dans l'ordre indiqué. Dans le cas contraire, il est parcouru avant tout autre élément du chemin.

  De même, le schéma des tables temporaires, `pg_temp_`nnn``, s'il existe, est toujours parcouru. Il peut être explicitement ajouté au chemin à l'aide de l'alias `pg_temp`. S'il n'en fait pas partie, la recherche commence 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 est jamais recherché.

  Lorsque des objets sont créés sans précision de schéma cible particulier, ils sont placés dans le premier schéma valide 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`. Elle permet l'utilisation partagée d'une base de données (dans laquelle aucun utilisateur n'a de schéma privé et tous partagent l'utilisation de `public`), les schémas privés d'utilisateur ainsi qu'une combinaison de ces deux modes. D'autres effets peuvent être obtenus en modifiant le chemin de recherche par défaut, globalement ou par utilisateur.

  La valeur courante réelle du chemin de recherche peut être examinée via la fonction SQL `current_schemas()` (voir Section 9.26). Elle n'est pas identique à la valeur de `search_path` car `current_schemas` affiche la façon dont les requêtes apparaissant dans `search_path` sont résolues.

`row_security` (`boolean`)

  Cette variable indique s'il convient de lever une erreur au lieu d'appliquer la politique de sécurité au niveau ligne. Lorsque positionnée à `on`, les politiques s'appliquent normalement. Lorsque positionnée à `off`, les requêtes qui remplissent les conditions d'au moins une politique de sécurité échouent. La valeur par défaut est `on`. Positionnez la valeur sur `off` dans le cas où une visibilité limitée des lignes pourrait causer des résultats incorrects ; par exemple, pg_dump effectue ce changement par défaut. Cette variable n'a aucun effet sur les rôles qui outrepassent toutes les politiques de sécurité niveau ligne, à savoir, les super-utilisateurs et les rôles qui possèdent l'attribut `BYPASSRLS`.

  Pour plus d'informations sur les politiques de sécurité niveau ligne, voir CREATE POLICY.

`default_table_access_method` (`string`)

  Ce paramètre spécifie la méthode d'accès par défaut aux tables. Ce paramètre est utilisé lors de la création des tables ou des vues matérialisées si la commande `CREATE` n'indique pas spécifiquement de méthode d'accès ou quand `SELECT ... INTO` est utilisé, ce qui ne permet pas de spécifier une méthode d'accès à la table. La valeur par défaut est `heap`.

`default_tablespace` (`string`)

  Cette variable indique le tablespace par défaut dans lequel sont créés les objets (tables et index) quand une commande `CREATE` ne l'explicite pas.

  La valeur est soit le nom d'un tablespace soit une chaîne vide pour indiquer l'utilisation du tablespace par défaut de la base de données courante. Si la valeur ne correspond pas au nom d'un tablespace existant, PostgreSQL utilise automatiquement le tablespace par défaut de la base de données courante. Si un tablespace différent de celui par défaut est indiqué, l'utilisateur doit avoir le droit `CREATE`. Dans le cas contraire, la tentative de création échouera.

  Cette variable n'est pas utilisée pour les tables temporaires ; pour elles, temp_tablespaces est consulté à la place.

  Cette variable n'est pas utilisée non plus lors de la création de bases de données. Par défaut, une nouvelle base de données hérite sa configuration de tablespace de la base de données modèle qui sert de copie.

  Si ce paramètre est configuré à une valeur autre que la chaîne vide quand une table partitionnée est créée, le tablespace de la table partitionnée sera configuré à cette valeur, qui sera utilisé comme tablespace par défaut pour les partitions créées dans le futur, même si `default_tablespace` a été modifié depuis.

  Pour plus d'informations sur les tablespaces, voir Section 23.6.

`default_toast_compression` (`enum`)

  Ce paramètre configure la valeur par défaut pour la méthode de compression des colonnes TOAST des nouvelles tables. La commande `CREATE TABLE` peut surcharger cette valeur par défaut si la clause `COMPRESSION` est utilisée au niveau des colonnes. Les méthodes de compression supportées sont `pglz` et, si PostgreSQL a été compilé avec l'option `--with-lz4`, `lz4`. La valeur par défaut est `pglz`.

`temp_tablespaces` (`string`)

  Cette variable indique le (ou les) tablespace(s) dans le(s)quel(s) créer les objets temporaires (tables temporaires et index sur des tables temporaires) quand une commande `CREATE` n'en explicite pas. Les fichiers temporaires créés par les tris de gros ensembles de données sont aussi créés dans ce tablespace.

  Cette valeur est une liste de noms de tablespaces. Quand cette liste contient plus d'un nom, PostgreSQL choisit un membre de la liste au hasard à chaque fois qu'un objet temporaire doit être créé. En revanche, dans une transaction, les objets temporaires créés successivement sont placés dans les tablespaces successifs de la liste. Si l'élément sélectionné de la liste est une chaîne vide, PostgreSQL utilise automatiquement le tablespace par défaut de la base en cours.

  Si `temp_tablespaces` est configuré interactivement, l'indication d'un tablespace inexistant est une erreur. Il en est de même si l'utilisateur n'a pas le droit `CREATE` sur le tablespace indiqué. Néanmoins, lors de l'utilisation d'une valeur précédemment configurée, les tablespaces qui n'existent pas sont ignorés comme le sont les tablespaces pour lesquels l'utilisateur n'a pas le droit `CREATE`. Cette règle s'applique, en particulier, lors de l'utilisation d'une valeur configurée dans le fichier `postgresql.conf`.

  La valeur par défaut est une chaîne vide. De ce fait, tous les objets temporaires sont créés dans le tablespace par défaut de la base de données courante.

  Voir aussi default_tablespace.

`check_function_bodies` (`boolean`)

  Ce paramètre est habituellement positionné à `on`. Positionné à `off`, il désactive la validation du corps de la routine lors de CREATE FUNCTION et CREATE PROCEDURE. Désactiver la validation évite les effets de bord du processus de validation, en particulier pour éviter les faux positifs dûs à des problèmes tels que les références. Configurer ce paramètre à `off` avant de charger les fonctions à la place des autres utilisateurs ; pg_dump le fait automatiquement.

`default_transaction_isolation` (`enum`)

  Chaque transaction SQL a un niveau d'isolation. Celui-ci peut être « read uncommitted », « read committed », « repeatable read » ou « 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 ».

  Consulter le Chapitre 13 et SET TRANSACTION pour plus d'informations.

`default_transaction_read_only` (`boolean`)

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

  Consulter SET TRANSACTION pour plus d'informations.

`default_transaction_deferrable` (`boolean`)

  Lors du fonctionnement avec le niveau d'isolation `serializable`, une transaction SQL en lecture seule et différable peut subir un certain délai avant d'être autorisée à continuer. Néanmoins, une fois qu'elle a commencé son exécution, elle n'encourt aucun des frais habituels nécessaires pour assurer sa sériabilité. Donc le code de sérialisation n'a aucune raison de forcer son annulation à cause de mises à jour concurrentes, ce qui rend cette option très intéressante pour les longues transactions en lecture seule.

  Ce paramètre contrôle le statut différable par défaut de chaque nouvelle transaction. Il n'a actuellement aucun effet sur les transactions en lecture/écriture ou celles opérant à des niveaux d'isolation inférieurs à `serializable`. La valeur par défaut est `off`.

  Consultez SET TRANSACTION pour plus d'informations.

`transaction_isolation` (`enum`)

  Ce paramètre reflète le niveau d'isolation de la transaction. Au début de chaque transaction, il est configuré à la valeur courante du paramètre default_transaction_isolation. Toute tentative ultérieure de modification est équivalente à une commande SET TRANSACTION.

`transaction_read_only` (`boolean`)

  Ce paramètre reflète le statut lecture-seule de la transaction courante. Au début de chaque transaction, il est configuré à la valeur courante du paramètre default_transaction_read_only. Toute tentative de modification ultérieure est équivalente à une commande SET TRANSACTION.

`transaction_deferrable` (`boolean`)

  Ce paramètre reflète le statut de reportabilité de la transaction courante. Au début de chaque transaction, il est configuré à la valeur courante du paramètre default_transaction_deferrable. Toute tentative de modification ultérieure est équivalente à une commande SET TRANSACTION.

`session_replication_role` (`enum`)

  Contrôle l'exécution des triggers et règles relatifs à la réplication pour la session en cours. Seul un super-utilisateur peut configurer cette variable. Sa modification résulte en l'annulation de tout plan de requête précédemment mis en cache. Les valeurs possibles sont `origin` (la valeur par défaut), `replica` et `local`.

  L'utilisation prévue de ce paramètre est que les systèmes de réplication logique le passent à `replica` quand ils répliquent des changements. L'effet sera que les triggers et les règles (quand on n'a pas modifié la configuration par défaut) ne se déclencheront pas sur la réplique. Voir les clauses `ALTER TABLE` `ENABLE TRIGGER` et `ENABLE RULE` pour plus d'informations.

  En interne, PostgreSQL traite de la même manière les paramètres `origin` et `local`. Les systèmes de réplication tiers peuvent utiliser ces deux valeurs pour leurs besoins internes, par exemple en utilisant `local` pour désigner la session dont les changements ne seront pas répliqués.

  Puisque les clés étrangères sont implémentées comme des triggers, passer ce paramètre à `replica` désactive aussi toutes les vérifications de clés étrangères, ce qui peut laisser les données dans un état incohérent en cas d'utilisation inappropriée.

`statement_timeout` (`integer`)

  Interrompt toute instruction qui dure plus longtemps que cette durée. Si `log_min_error_statement` est configuré à `ERROR`, ou plus bas, l'instruction en cause est tracée. Si cette valeur est indiquée sans unité, elle est comprise comme un nombre de millisecondes. La valeur zéro (par défaut) désactive le décompte.

  Le délai est mesuré à partir du moment où une commande arrive au serveur jusqu'à sa fin par le serveur. Si plusieurs requêtes SQL apparaissent dans un seul message simple-Query, le délai est appliqué à chaque requête séparément. (Les versions de PostgreSQL antérieures à la 13 traitaient le délai pour la chaîne complète de requêtes.) Dans le protocole de requête étendue, le délai commence lors du début de l'exécution de tout message relatif à la requête (Parse, Bind, Execute, Describe) et elle est annulée à la fin du message Execute ou Sync.

  Il n'est pas recommandé de configurer `statement_timeout` dans `postgresql.conf` car cela affecte toutes les sessions.

`lock_timeout` (`integer`)

  Annule toute requête qui attend plus longtemps que la durée indiquée par ce paramètre lors de la tentative d'acquisition d'un verrou sur une table, un index, une ligne ou tout autre objet d'une base de données. La limite de temps s'applique séparément pour chaque tentative d'acquisition d'un verrou. La limite s'applique pour les demandes de verrous explicites (comme `LOCK TABLE`, ou `SELECT FOR UPDATE` sans `NOWAIT`) et pour ceux acquis implicitement. Si cette valeur est indiquée sans unité, elle est comprise comme un nombre de millisecondes. Une valeur de zéro (valeur par défaut) désactive ce comportement.

  Contrairement à `statement_timeout`, ce délai peut seulement intervenir lors de l'attente de verrous. Notez que si `statement_timeout` est différent de zéro, il est plutôt inutile de configurer `lock_timeout` à la même valeur ou à une valeur plus importante puisque le délai sur la requête se déclenchera toujours avant. Si `log_min_error_statement` est configuré à `ERROR` ou plus bas, l'instruction qui dépasse ce délai sera tracé.

  Configurer `lock_timeout` dans `postgresql.conf` n'est pas recommandé car cela affecterait toutes les sessions.

`idle_in_transaction_session_timeout` (`integer`)

  Termine toute session inactive (c'est-à-dire qui attend que le client envoie une requête) alors qu'une transaction est en cours depuis plus longtemps que le temps indiqué. Si cette valeur est fournie sans unité, elle est comprise en millisecondes. Une valeur à zéro (qui est la valeur par défaut) désactive ce délai.

  Cette option peut être utilisée pour s'assurer que des sesions inactives ne conservent pas des verrous sur une durée déraisonnable. Même lorsqu'aucun verrou non important est réservé, une transaction ouverte empêche de nettoyer correctement les lignes mortes les plus récentes qui peuvent n'être plus visibles que par cette transaction. Conserver des transactions inactives alors qu'une transaction est ouverte peut donc ainsi augmenter la fragmentation des données. Voir Section 25.1 pour plus d'information.

`idle_session_timeout` (`integer`)

  Termine toute transaction inactive depuis plus longtemps que le temps indiqué(c'est-à-dire qui attend que le client envoie une requête), mais pour laquelle aucune transaction n'est en cours. Si cette valeur est fournie sans unité, elle est comprise en millisecondes. Une valeur à zéro (qui est la valeur par défaut) désactive ce délai.

  Contrairement au cas des transactions en cours, une session inactive sans transaction en cours ne prend pas beaucoup de ressources sur le serveur. Il est donc moins nécessaire d'activer ce paramètre que `idle_in_transaction_session_timeout`.

  Attention à l'utilisation de ce paramètre avec certains logiciels comme un pooler de connexions ou un autre logiciel tiers car ce type de logiciels pourrait mal gérer la fermeture inopinée des connexions. Il peut être intéressant de n'activer ce délai que pour les sessions interactives, peut-être en appliquant ce paramètre qu'à certains utilisateurs.

`vacuum_freeze_table_age` (`integer`)

  `VACUUM` effectuera un parcours agressif de la table si le champ `pg_class`.`relfrozenxid` de la table a atteint l'âge spécifié par ce paramètre. Un parcours agressif diffère d'un `VACUUM` standard dans le sens où il visite chaque bloc qui pourrait contenir des XID ou MXID non gelés, pas seulement ceux qui pourraient contenir des lignes mortes. La valeur par défaut est 150 millions de transactions. Même si les utilisateurs peuvent positionner cette valeur à n'importe quelle valeur comprise entre zéro et 2 milliards, `VACUUM` limitera silencieusement la valeur effective à 95% de autovacuum_freeze_max_age, afin qu'un vacuum périodique manuel ait une chance de s'exécuter avant un autovacuum anti-bouclage ne soit lancé pour la table. Pour plus d'informations voir Section 25.1.5.

`vacuum_freeze_min_age` (`integer`)

  Indique l'âge limite (en transactions) que `VACUUM` doit utiliser pour décider de geler les versions de ligne lors du parcours d'une table. La valeur par défaut est 50 millions. Bien que les utilisateurs puissent configurer une valeur quelconque comprise entre zéro et 1 milliard, `VACUUM` limite silencieusement la valeur réelle à la moitié de la valeur de autovacuum_freeze_max_age afin que la valeur entre deux autovacuums forcés ne soit pas déraisonnablement courte. Pour plus d'informations, voir Section 25.1.5.

`vacuum_failsafe_age` (`integer`)

  Spécifie l'âge maximum (en transactions) que le champ `pg_class`.`relfrozenxid` d'une table peut atteindre avant qu'un `VACUUM` ne prenne des mesures exceptionnelles pour empêcher un arrêt du système lié à un risque de bouclage des identifiants de transaction (ID wraparound). Il s'agit d'une stratégie que le `VACUUM` n'applique qu'en dernier recours. Cette sécurité est déclenchée généralement quand un autovacuum pour empêcher le bouclage des identifiants de transaction tourne depuis quelque temps, même si rien n'empêche ce fonctionnement exceptionnel de se déclencher pendant un `VACUUM`.

  Lorsque cette sécurité est déclenchée, tout délai basé sur les coûts est ignoré et d'autres tâches de maintenance non essentielles (comme le vacuum des index) sont reportées.

  La valeur par défaut est 1,6 milliards de transactions. Même s'il est possible de fournir une valeur entre 0 et 2,1 milliards, `VACUUM` ajustera cette valeur pour qu'elle ne dépasse pas 105% de autovacuum_freeze_max_age.

`vacuum_multixact_freeze_table_age` (`integer`)

  `VACUUM` réalise un parcours agressif de la table si le champ `pg_class`.`relminmxid` de la table a atteint l'âge indiqué par ce paramètre. Un parcours agressif diffère d'un `VACUUM` standard dans le sens où il visite chaque bloc qui pourrait contenir des XID ou MXID non gelés, pas seulement ceux qui pourraient contenir des lignes mortes. La valeur par défaut est de 150 millions de multixacts. Bien que les utilisateurs peuvent configurer cette valeur entre zéro et deux milliards, `VACUUM` limitera silencieusement la valeur réelle à 95% de autovacuum_multixact_freeze_max_age, pour qu'un `VACUUM` manuel périodique ait une chance d'être exécuté avant qu'une opération anti-réutilisation d'identifiants ne soit exécutée sur la table. Pour plus d'informations, voir Section 25.1.5.1.

`vacuum_multixact_freeze_min_age` (`integer`)

  Précise l'âge limite (en multixacts) que `VACUUM` doit utiliser pour décider s'il doit remplacer les identifiants multixact avec un nouvel identifiant de transaction ou de multixact lors de son parcours de la table. La valeur par défaut est de 5 millions de multixacts. Bien que les utilisateurs peuvent configurer cette valeur entre zéro et un milliard, `VACUUM` limitera silencieusement la valeur réelle à la moitié de la valeur de autovacuum_multixact_freeze_max_age, pour qu'il y ait un délai raisonnable entre deux autovacuums forcés. Pour plus d'informations, voir Section 25.1.5.1.

`vacuum_multixact_failsafe_age` (`integer`)

  Spécifie l'âge maximum (en transactions) que le champ `pg_class`.`relminxid` d'une table peut atteindre avant qu'un `VACUUM` ne prenne des mesures exceptionnelles pour empêcher un arrêt du système lié à un risque de bouclage des identifiants de transaction (ID wraparound). Il s'agit d'une stratégie que le `VACUUM` n'applique qu'en dernier recours. Cette sécurité est déclenchée généralement quand un autovacuum pour empêcher le bouclage des identifiants de transaction tourne depuis quelque temps, même si rien n'empêche ce fonctionnement exceptionnel de se déclencher pendant un `VACUUM`.

  Lorsque cette sécurité est déclenchée, tout délai basé sur les coûts est ignoré et d'autres tâches de maintenance non essentielles (comme le vacuum des index) sont reportées.

  La valeur par défaut est 1,6 milliards de transactions. Même s'il est possible de fournir une valeur entre 0 et 2,1 milliards, `VACUUM` ajustera cette valeur pour qu'elle ne dépasse pas 105% de autovacuum_multixact_freeze_max_age.

`bytea_output` (`enum`)

  Configure le format de sortie pour les valeurs de type `bytea`. Les valeurs valides sont `hex` (la valeur par défaut) et `escape` (le format traditionnel de PostgreSQL). Voir Section 8.4 pour plus d'informations. Le type `bytea` accepte toujours les deux formats en entrée, quelque soit la valeur de cette configuration.

`xmlbinary` (`enum`)

  Définit la manière de coder les valeurs binaires en XML. Ceci s'applique, par exemple, quand les valeurs `bytea` sont converties en XML par les fonctions `xmlelement` et `xmlforest`. Les valeurs possibles sont `base64` et `hex`, qui sont toutes les deux définies dans le standard XML Schema. La valeur par défaut est `base64`. Pour plus d'informations sur les fonctions relatives à XML, voir Section 9.15.

  Le choix effectif de cette valeur est une affaire de sensibilité, la seule restriction provenant des applications clientes. Les deux méthodes supportent toutes les valeurs possibles, et ce bien que le codage hexadécimal soit un peu plus grand que le codage en base64.

`xmloption` (`enum`)

  Définit si `DOCUMENT` ou `CONTENT` est implicite lors de la conversion entre XML et valeurs chaînes de caractères. Voir Section 8.13 pour la description. Les valeurs valides sont `DOCUMENT` et `CONTENT`. La valeur par défaut est `CONTENT`.

  D'après le standard SQL, la commande pour configurer cette option est :

      SET XML OPTION { DOCUMENT | CONTENT };

  Cette syntaxe est aussi disponible dans PostgreSQL.

### 20.11.2. Préchargement de bibliothèques partagées

Plusieurs paramètres sont disponibles pour le préchargement de bibliothèques partagées sur le serveur. Ces bibliothèques peuvent servir à ajouter des fonctionnalités supplémentaires ou à améliorer les performances. Par exemple, une configuration à `'$libdir/mabibliotheque'` force le chargement de la bibliothèque `mabibliotheque.so` (ou sur certaines plateformes de `mabibliotheque.sl`) à partir du répertoire standard d'installation. Les différences entre les paramètres concernent la prise d'effet et les droits requis pour les modifier.

Les bibliothèques de procédures stockées pour PostgreSQL peuvent être préchargées de cette façon, habituellement en utilisant la syntaxe `'$libdir/plXXX'` où `XXX` est `pgsql`, `perl`, `tcl` ou `python`.

Seules les bibliothèques partagées spécifiquement codées pour PostgreSQL peuvent être chargées de cette façon. Chaque bibliothèque supportée par PostgreSQL a un « bloc magique » qui est vérifié pour garantir sa comptabilité. De ce fait, les bibliothèques non compatibles avec PostgreSQL ne peuvent pas être gérées ainsi. Vous devriez pouvoir utiliser les capacités du système pour cela, tel que la variable d'environnement `LD_PRELOAD`.

En général, il est préférable de se référer à la documentation d'un module spécifique pour trouver le bon moyen permettant de charger le module.

`local_preload_libraries` (`string`)

  Cette variable indique une ou plusieurs bibliothèques partagées chargées au début de la connexion. Elle contient une liste de noms de bibliothèques, séparés par des virgules, où chaque nom est interprété comme par la commande `LOAD`. Les espaces blancs entre les entrées sont ignorés. Placer le nom d'une bibliothèque entre guillemets doubles si vous avez besoin d'inclure des espaces blancs ou des virgules dans le nom. La valeur de ce paramètre n'est pris en compte qu'au début de la connexion. Les modifications ultérieures n'ont pas d'effet sur les connexions déjà établies. Si une bibliothèque indiquée est introuvable, la tentative de connexion échouera. Seuls les super-utilisateurs peuvent modifier cette configuration.

  Cette option est configurable par tout utilisateur. De ce fait, les bibliothèques pouvant être chargées sont restreintes à celles disponibles dans le sous-répertoire `plugins` du répertoire des bibliothèques de l'installation. C'est de la responsabilité de l'administrateur de s'assurer que seules des bibliothèques « sûres » y soient installées.) Les éléments de `local_preload_libraries` peuvent indiquer ce répertoire explicitement, par exemple `$libdir/plugins/mabibliotheque`, ou indiquer seulement le nom de la bibliothèque -- `mabibliotheque`, ce qui aurait le même effet que `$libdir/plugins/mabibliotheque`.

  Le but de cette fonctionnalité est de permettre aux utilisateurs non privilégiés de charger des bibliothèques de débuggage ou de mesures de performances dans des sessions explicites sans avoir à exécuter manuellement une commande `LOAD`. À cette fin, une configuration classique de ce paramètre serait d'utiliser la variable d'environnement `PGOPTIONS` sur le client ou d'utiliser la commande `ALTER ROLE SET`.

  Néanmoins, sauf si un module est conçu spécifiquement pour être utilisé de cette façon par des utilisateurs non administrateurs, ceci n'est pas le bon paramétrage pour vous. Regardez plutôt session_preload_libraries.

`session_preload_libraries` (`string`)

  Cette variable indique une ou plusieurs bibliothèques partagées chargées au début de la connexion. Elle contient une liste de noms de bibliothèques, séparés par des virgules, où chaque nom est interprété comme par la commande `LOAD`. Les espaces blancs entre les entrées sont ignorés. Placer le nom d'une bibliothèque entre guillemets doubles si vous avez besoin d'inclure des espaces blancs ou des virgules dans le nom. La valeur de ce paramètre n'est pris en compte qu'au début de la connexion. Les modifications ultérieures n'ont pas d'effet sur les connexions déjà établies. Si une bibliothèque indiquée est introuvable, la tentative de connexion échouera. Seuls les super-utilisateurs peuvent modifier cette configuration.

  Le but de cette fonctionnalité est de permettre le chargement de bibliothèques de débuggage ou de mesure de performances dans des sessions explicites sans avoir à exécuter manuellement une commande `LOAD`. Par exemple, auto_explain pourrait être activé pour toutes les sessions si un certain utilisateur se connecte, en configurant son compte avec la commande `ALTER ROLE SET`. De plus, ce paramètre peut être modifié sans avoir à redémarrer le serveur (les changements ne prennent effet que pour les connexions suivantes), donc il est plus facile d'ajouter de nouveaux modules de cette façon, même s'ils s'appliquent à toutes les sessions.

  Contrairement à shared_preload_libraries, il n'y a pas vraiment un gros avantage en terme de performances à charger une bibliothèque en début de session plutôt qu'à sa première utilisation. Néanmoins, ceci n'est plus vrai si un système de pooling de connexions est mis en place.

`shared_preload_libraries` (`string`)

  Cette variable indique une ou plusieurs bibliothèques partagées chargées au démarrage du serveur. Elle contient une liste de noms de bibliothèques, séparés par des virgules, où chaque nom est interprété comme par la commande `LOAD`. Les espaces blancs entre les entrées sont ignorés. Placer le nom d'une bibliothèque entre guillemets doubles si vous avez besoin d'inclure des espaces blancs ou des virgules dans le nom. La valeur de ce paramètre n'est pris en compte qu'au démarrage du serveur. Si une bibliothèque indiquée est introuvable, la tentative de démarrage échouera. Seuls les super-utilisateurs peuvent modifier cette configuration.

  Certaines bibliothèques ont besoin de réaliser certaines opérations qui ne peuvent se faire qu'au démarrage du processus postmaster, comme allouer de la mémoire partagée, réserver des verrous à faible poids, ou démarrer des background workers. Ces bibliothèques doivent être chargées au démarrage du serveur via ce paramètre. Voir la documentation de chaque bibliothèque pour les détails.

  Les autres bibliothèques peuvent aussi être préchargées. En préchargeant une bibliothèque partagée, le temps de démarrage de la bibliothèque est évité lorsque la bibliothèque est utilisée pour la première fois. Néanmoins, le temps de démarrer chaque nouveau processus serveur pourrait augmenter légèrement, même si le processus n'utilise jamais cette bibliothèque. Donc ce paramètre est seulement recommandé pour les bibliothèques qui seront utilisées par la majorité des sessions. De plus, changer ce paramètre requiert un redémarrage du serveur, donc ce n'est pas le bon paramètre pour les tâches de débuggage par exemple. Utilisez session_preload_libraries pour cela.

  ### Note

  Sur les hôtes Windows, précharger une bibliothèque au démarrage du serveur ne réduira pas le temps nécessaire pour démarrer un nouveau processus serveur. Chaque processus serveur rechargera toutes les bibliothèques préchargées. Néanmoins, `shared_preload_libraries` est toujous utile sur les hôtes Windows pour les bibliothèques qui ont besoin de réaliser des opérations au démarrage du postmaster.

`jit_provider` (`string`)

  Cette variable contient le nom de la bibliothèque du fournisseur JIT à utiliser (voir Section 32.4.2). La valeur par défaut est `llvmjit`. Ce paramètre n'est configurable qu'au démarrage du serveur.

  Si ce paramètre pointe vers une bibliothèque inexistante, JIT ne sera pas disponible, mais aucune erreur ne sera levée. Cela permet à l'infrastructure de JIT d'être installée séparément de l'installation PostgreSQL principale.

`gin_pending_list_limit` (`integer`)

  Positionne la taille maximale de la liste d'attente GIN qui est utilisée lorsque `fastupdate` est activé. Si la liste dépasse cette taille maximale, elle est allégée en déplaçant des entrées en masse vers la structure de données principale GIN. Si cette valeur est indiquée sans unité, elle est comprise comme un nombre de Ko. La valeur par défaut est quatre mégaoctets (`4MB`). Ce paramètre peut être surchargé pour chaque index GIN en modifiant les paramètres de stockage de l'index. Voir Section 67.4.1 et Section 67.5 pour plus d'informations.

`restrict_nonsystem_relation_kind` (`string`)

  Configure le type de relation dont l'accès est restreint pour les relations utilisateurs. La valeur configurée doit être une liste séparée par des virgules de type de relation. Actuellement, les types de relation acceptés sont `view` et `foreign-table`.

### 20.11.3. Locale et formatage

`datestyle` (`string`)

  Configure le format d'affichage des valeurs de type date et heure, ainsi que les règles d'interprétation des valeurs ambiguës de dates saisies. Pour des raisons historiques, cette variable contient deux composantes indépendantes : la spécification du format en sortie (`ISO`, `Postgres`, `SQL` ou `German`) et la spécification en entrée/sortie de 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 des synonymes de `DMY` ; les mots clés `US`, `NonEuro` et `NonEuropean` sont des synonymes de `MDY`. Voir la Section 8.5 pour plus d'informations. La valeur par défaut est `ISO, MDY`, mais initdb initialise le fichier de configuration avec une valeur qui correspond au comportement de la locale `lc_time` choisie.

`IntervalStyle` (`enum`)

  Positionne le format d'affichage pour les valeurs de type intervalle. La valeur `sql_standard` produira une sortie correspondant aux litéraux d'intervalles du standard SQL. La valeur `postgres` (qui est la valeur par défaut) produira une sortie correspondant à celle des versions de PostgreSQL antérieures à la 8.4 quand le paramètre datestyle était positionné à `ISO`. La valeur `postgres_verbose` produira une sortie correspondant à celle des versions de PostgreSQL antérieures à la 8.4 quand le paramètre `DateStyle` était positionné à une valeur autre que `ISO` La valeur `iso_8601` produira une sortie correspondant au « format avec designateurs » d'intervalle de temps défini dans le paragraphe 4.4.3.2 de l'ISO 8601.

  Le paramètre `IntervalStyle` affecte aussi l'interprétation des entrées ambigües d'intervalles. Voir Section 8.5.4 pour plus d'informations.

`TimeZone` (`string`)

  Configure le fuseau horaire pour l'affichage et l'interprétation de la date et de l'heure. La valeur par défaut est `GMT`, mais elle est généralement surchargée dans le fichier `postgresql.conf` ; initdb installera une configuration correspondant à l'environnement système. Voir Section 8.5.3 pour plus d'informations.

`timezone_abbreviations` (`string`)

  Configure la liste des abréviations de fuseaux horaires acceptés par le serveur pour la saisie de données de type datetime. La valeur par défaut est `'Default'`, qui est une liste qui fonctionne presque dans le monde entier ; il y a aussi `'Australia'` et `'India'`. D'autres listes peuvent être définies pour une installation particulière. Voir Section B.4 pour plus d'informations.

`extra_float_digits` (`integer`)

  Ce paramètre ajuste le nombre de chiffres utilisés par l'affichage textuel par les valeurs à virgule flottante, ce qui inclut `float4`, `float8` et les types de données géométriques.

  Si la valeur est 1 (valeur par défaut) ou au-dessus, les valeurs à virgule flottante sont renvoyées dans le format le plus court et le plus précis ; voir Section 8.1.3. Le nombre réel de chiffres générés dépends seulement de la valeur en sortie, et non pas de la valeur de ce paramètre. Au plus 17 chiffres sont requis pour les valeurs `float8` et 9 pour les valeurs `float4`. Ce format est à la fois rapide et précis, préservant exactement la valeur flottante binaire originale lorsqu'elle est correctement lue. Pour la compabilité historique, des valeurs jusqu'à 3 sont autorisées.

  Si la valeur est zéro ou négative, alors la sortie est arrondie avec une précision décimale donnée. La précision utilisée est le nombre standard de chiffres pour le type (`FLT_DIG` ou `DBL_DIG` comme approprié) réduit suivant la valeur de ce paramètre. (Par exemple, indiquer -1 fera que les valeurs `float4` soient arrondies en sortie à 5 chiffres significatifs et les valeurs `float8` à 14 chiffres.) Ce format est plus lent et ne préserve pas tous les buts de la valeur flottante binaire, mais pourrait être plus facile à lire.

  ### Note

  La signification de ce paramètre, et de sa valeur par défaut, a changé avec PostgreSQL 12 ; voir Section 8.1.3 pour plus de discussions.

`client_encoding` (`string`)

  Initialise l'encodage client (jeu de caractères). Par défaut, il s'agit de celui de la base de données. Les ensembles de caractères supportés par PostgreSQL sont décrits dans Section 24.3.1.

`lc_messages` (`string`)

  Initialise la langue d'affichage des messages. Les valeurs acceptables dépendent du système ; voir Section 24.1 pour plus d'informations. Si cette variable est initialisée à une chaîne vide (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 fonctionne toujours mais n'a aucun effet. De même, il est possible qu'il n'existe pas de traduction des messages dans la langue sélectionnée. Dans ce cas, les messages sont affichés en anglais.

  Seuls les super-utilisateurs peuvent modifier ce paramètre car il affecte aussi bien les messages envoyés dans les traces du serveur que ceux envoyés au client.

`lc_monetary` (`string`)

  Initialise la locale à utiliser pour le formatage des montants monétaires (pour la famille de fonctions `to_char`, par exemple). Les valeurs acceptables dépendent du système ; voir la Section 24.1 pour plus d'informations. Si cette variable est initialisée à une chaîne vide (valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur, et une valeur incorrecte pourrait dégrader la lisibilité des traces du serveur.

`lc_numeric` (`string`)

  Initialise la locale à utiliser pour le formatage des nombres (pour la famille de fonctions `to_char`, par exemple). Les valeurs acceptables dépendent du système ; voir la Section 24.1 pour plus d'informations. Si cette variable est initialisée à 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 le formatage des valeurs de date et d'heure, par exemple avec la famille de fonctions `to_char`. Les valeurs acceptables dépendent du système ; voir la Section 24.1 pour plus d'informations. Si cette variable est initialisée à une chaîne vide (valeur par défaut), alors la valeur est héritée de l'environnement d'exécution du serveur.

`default_text_search_config` (`string`)

  Sélectionne la configuration de recherche plein texte utilisée par les variantes des fonctions de recherche plein texte qui n'ont pas d'argument explicite pour préciser la configuration. Voir Chapitre 12 pour plus d'informations. La valeur par défaut est `pg_catalog.simple` mais initdb initialise le fichier de configuration avec une valeur qui correspond à la locale choisie pour `lc_ctype` s'il est possible d'identifier une configuration correspondant à la locale.

### 20.11.4. Autres valeurs par défaut

`dynamic_library_path` (`string`)

  Chemin de recherche utilisé lorsqu'un module chargeable dynamiquement doit être ouvert et que le nom de fichier indiqué dans la commande `CREATE FUNCTION` ou `LOAD` ne contient pas d'indication de répertoire (c'est-à-dire que le nom ne contient pas de slash).

  La valeur de `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 débute par 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. (La commande `pg_config --pkglibdir` permet de 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'

  Pour plus d'informations sur la gestion des schémas, voir Section 5.9. En particulier, la configuration par défaut est seulement convenable quand la base de données a un seul utilisateur ou quelques utilisateurs qui se font confiance mutuellement.

  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 super-utilisateurs, mais un tel paramétrage ne persiste que pour la durée de la connexion du client. Il est donc préférable de ne réserver cette méthode qu'à des fins de développement. Il est recommandé d'initialiser ce paramètre dans le fichier de configuration `postgresql.conf`.

`gin_fuzzy_search_limit` (`integer`)

  Limite souple haute de la taille de l'ensemble renvoyé par un index GIN. Pour plus d'informations, voir Section 67.5.