Autorise la création de tablespaces dans des répertoires à l'intérieur de pg_tblspc, quand une chaîne vide d'emplacement est fournie à la commande. Ceci a pour but de permettre de tester des scénarios de réplication où les serveurs primaire et secondaire sont exécutées sur la même machine. De tels répertoires pourraient gêner les outils de sauvegarde qui s'attendent à ne trouver que des lien symboliques dans ce répertoire. Seuls les superutilisateurs et les utilisateurs avec le droit SET approprié peuvent modifier cette configuration.

Permet les modifications de la structure de tables systèmes ainsi que certaines autres actions risquées sur les tables systèmes. Ceci n'est autrement pas autorisé, y compris pour les superutilisateurs. Une mauvaise utilisation de ce paramètre peut causer des pertes de données irrécupérables ou une corruption sérieuse du système de bases de données. Seuls les superutilisateurs et les utilisateurs disposant des droits SET adéquats peuvent modifier ce paramètre.

Ce paramètre contient une liste de noms de fonctions C séparés par des virgules. Si une erreur est levée et que le nom d'une fonction C où une erreur survient correspond à une valeur de la liste, alors la pile d'appel est écrite dans les traces du serveur avec le message d'erreur. Ceci peut être utilisé pour déboguer des aires spécifiques du code source.

Cette fonctionnalité n'est pas disponibles sur toutes les plateformes et la qualité des traces dépend des options de compilation.

Ce paramètre peut seulement être configuré par les superutilisateurs et les utilisateurs disposant des droits SET adéquats.

Quand il est configuré à 1, chaque entrée cache du catalogue système est invalidé dès la première opportunité, que ces entrées soient invalides ou pas. Le maintien en cache du catalogue système est de fait désactivé, le serveur sera donc plus lent. Des valeurs plus grandes permettent de faire tourner l'invalidation du cache de manière récursive, ce qui rendra le serveur encore plus lent. Ce paramètre n'est utile que pour tester la logique du cache elle-même. La valeur par défaut est 0 et permet d'avoir un comportement normal du cache du catalogue système.

Ce paramètre peut être très utile lorsqu'on essaye de reproduire un bug lié à des changements concurrents du catalogue système. Dans tous les autres cas, il est rarement utile. Lisez le code source de inval.c et pg_config_manual.h pour plus d'informations.

Ce paramètre est accepté quand CLOBBER_CACHE_ENABLED a été défini lors de la compilation (ce qui se fait automatiquement lorsqu'on utilise l'outil configure avec l'option --enable-cassert). Sur un système de production, la valeur de ce paramètre sera toujours 0 et tenter de le changer ramènera une erreur.

Demande au noyau de minimiser les effets de mise en cache pour les données des relations et des fichiers de transactions WAL utilisant O_DIRECT (pour la plupart des systèmes de type Unix), F_NOCACHE (macOS) ou FILE_FLAG_NO_BUFFERING (Windows).

Peut être défini comme une chaîne vide (valeur par défaut) pour désactiver l'utilisation d'entrées/sorties directes, ou une liste d'opérations séparées par des virgules qui doivent utiliser des entrées/sorties directes. Les options valides sont data pour les fichiers de données principaux, wal pour les fichiers de transactions, et wal_init pour les fichiers de transactions WAL lors de leur création initiale.

Certains systèmes d'exploitation et systèmes de fichiers ne prennent pas en charge les entrées/sorties directes. Les paramètres autres que ceux par défaut peuvent être rejetés au démarrage ou provoquer des erreurs.

Actuellement, cette fonctionnalité réduit les performances et est destinée aux tests des développeurs uniquement.

Permet la parallélisation des requêtes à des fins de test, même dans les cas où aucune amélioration de performance n'est attendue. Les valeurs autorisées de force_parallel_mode sont off (la parallélisation n'est utilisée que si elle doit être bénéfique), on(la parallélisation est forcée pour toutes les requêtes pour lesquelles elle est considérée comme sans risque) et regress (comme on, mais avec quelques différences indiquées ci-dessous).

Positionner ce paramètre à on va ajouter un nœud de type Gather au début de chaque plan d'exécution lorsque cela n'est pas risqué, de manière à ce que la requête tourne au sein d'un processus parallèle. Ainsi, même lorsqu'un processus parallèle n'est pas disponible ou lorsqu'il ne peut pas être utilisé, pour la création de sous-transactions par exemple, un processus parallèle est créé à moins que le planificateur ne repère une opération ne pouvant pas être parallélisée. Si des erreurs ou des comportements inattendus sont constatés alors que ce paramètre est configuré à on, certaines fonctions utilisées dans la requête devront être marquées comme PARALLEL UNSAFE (ou sinon PARALLEL RESTRICTED).

Positionner ce paramètre à regress permet de bénéficier de tous les effets de la valeur on tout en ajoutant des fonctionnalités ayant pour but d'améliorer les tests de non régression automatisés. Normalement, les messages d'un processus de parallélisation incluent une ligne de contexte indiquant qu'il s'agit d'un processus de parallélisation, mais le positionnement du paramètre à regress supprime cette ligne de telle manière que la sortie est la même que pour une exécution non parallélisée. De plus, les nœuds de type Gather qui sont ajoutés au plan d'exécution sont cachées dans l'affichage de EXPLAIN de manière à ce que l'affichage soit le même que si le paramètre était positionné à off.

Ignore les index système lors de la lecture des tables système (mais continue de les mettre à jour lors de modifications des tables). Cela s'avère utile lors de la récupération d'index système endommagés. Ce paramètre ne peut pas être modifié après le démarrage de la session.

Durée d'attente, après l'étape d'authentification, lorsqu'un nouveau processus serveur est lancé. Ceci a pour but de donner l'opportunité aux développeurs d'attacher un débogueur au processus serveur. Si cette valeur est indiquée sans unité, elle est comprise pour un nombre de secondes. La valeur par défaut, 0, désactive ce délai. Ce paramètre ne peut pas être modifié après le démarrage de la session.

Durée d'attente, juste après la création d'un nouveau processus, avant le processus d'authentification. Ceci a pour but de donner une opportunité aux développeurs d'attacher un débogueur au processus serveur pour tracer les mauvais comportements pendant l'authentification. Si cette valeur est indiquée sans unité, elle est comprise pour un nombre de secondes. La valeur par défaut, 0, désactive ce délai. Ce paramètre ne peut être configuré que dans le fichier postgresql.conf ou indiqué sur la ligne de commande.

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

Si ce paramètre est actif, des informations concernant l'utilisation des ressources lors des opérations de tri sont émises. Ce paramètre n'est disponible que si la macro TRACE_SORT a été définie lors de la compilation de PostgreSQL (néanmoins, TRACE_SORT est actuellement définie par défaut).

Si activé, émet des informations à propos de l'utilisation des verrous. L'information fournie inclut le type d'opération de verrouillage, le type de verrou et l'identifiant unique de l'objet verrouillé ou déverrouillé. Sont aussi inclus les masques de bits pour les types de verrous déjà accordés pour cet objet, ainsi que pour les types de verrous attendus sur cet objet. Pour chaque type de verrou un décompte du nombre de verrous accordés et en attente est aussi retourné, ainsi que les totaux. Un exemple de sortie dans le journal applicatif est montré ici :

LOG:  LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(AccessShareLock)
LOG:  GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(2) req(1,0,0,0,0,0,0)=1 grant(1,0,0,0,0,0,0)=1
      wait(0) type(AccessShareLock)
LOG:  UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(AccessShareLock)
LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(INVALID)
      

Les détails de la structure retournée peuvent être trouvés dans src/include/storage/lock.h.

Ce paramètre n'est disponible que si la macro LOCK_DEBUG a été définie quand PostgreSQL a été compilé.

Si à on, génère des informations à propos de l'utilisation de verrous légers (lightweight lock). Les verrous légers servent principalement à fournir une exclusion mutuelle d'accès aux structures de données en mémoire partagée.

Ce paramètre n'est disponible que si la macro LOCK_DEBUG a été définie quand PostgreSQL a été compilé.

Si activé, génère des informations à propos de l'utilisation de verrous utilisateurs. La sortie est la même que pour trace_locks, mais restreinte aux verrous informatifs.

Si positionné, ne trace pas les verrouillages pour des tables en dessous de cet OID. (à utiliser pour ne pas avoir de sortie pour les tables systèmes)

Ce paramètre n'est disponible que si la macro LOCK_DEBUG a été définie quand PostgreSQL a été compilé.

Tracer les verrouillages sur cette table de façon inconditionnelle.

Ce paramètre n'est disponible que si la macro LOCK_DEBUG a été définie quand PostgreSQL a été compilé.

Si positionné, génère des informations à propos de tous les verrous en cours quand l'expiration de temps d'attente d'un verrou mortel se produit.

Ce paramètre n'est disponible que si la macro LOCK_DEBUG a été définie quand PostgreSQL a été compilé.

Si positionné, trace des statistiques d'utilisation de ressource système (mémoire et processeur) sur différentes opérations B-tree.

Ce paramètre n'est disponible que si la macro BTREE_BUILD_STATS a été définie quand PostgreSQL a été compilé.

Ce paramètre est destiné à être utiliser pour vérifier la présence de bugs dans les routines d'application de WAL. Une fois activé, des images de l'intégralité des pages sont ajoutés aux enregistrements. Si l'enregistrement est ensuite rejoué, le système appliquera d'abord chaque enregistrement et testera ensuite si les tampons modifiés par l'enregistrement correspond aux images stockées. Dans certains cas (comme les hint bits), des variations mineures sont acceptables, et seront ignorées. Toute différence inattendue provoquera une erreur fatale, ce qui arrêtera la restauration.

La valeur par défaut pour ce paramètre est une chaîne cide, ce qui désactive la fonctionnalité. Le paramètre peut être positionné à all pour vérifier tous les enregistrements, ou une liste séparée par des virgules de gestionnaires de sources afin de vérifier uniquement les enregistrements en fonction de ces gestionnaires de ressource. Actuellement, les gestionnaires de ressource supportés sont heap, heap2, btree, hash, gin, gist, sequence, spgist, brin, et generic. Les extensions peuvent définir des gestionnaires de ressources supplémentaires. Seuls les superutilisateurs et les utilisateurs disposant des droits SET adéquats peuvent modifier ce paramètre.

Si ce paramètre est positionné à on, une sortie de débogage relative aux WAL est émise. Ce paramètre n'est disponible que si la macro WAL_DEBUG a été définie au moment de la compilation de PostgreSQL.

Ne fonctionne que si data checksums est activé.

La détection d'un échec des sommes de vérification lors d'une lecture cause habituellement la levée d'une erreur par PostgreSQL, ce qui annule la transaction en cours. Activer ignore_checksum_failure fait que le système ignore l'échec (mais rapporte toujours un message d'avertissement) et continue le traitement. Ce comportement pourrait être la cause d'arrêts brutaux, de propagation ou de dissimulation de corruption, ou d'autres problème sérieux. Néanmoins, il peut vous permettre de dépasser l'erreur et de récupérer les lignes endommagées qui pourraient toujours être présentes dans la table si l'en-tête du bloc est sain. Si l'en-tête est corrompu, une erreur sera rapportée même si cette option est activée. La configuration par défaut est off, et elle ne peut être modifiée que par un superutilisateur et par les utilisateurs disposant des droits SET adéquats.

La détection d'un en_tête de page endommagé cause normalement le renvoi d'une erreur par PostgreSQL, annulant du même coup la transaction en cours. Activer zero_damaged_pages fait que le système renvoie un message d'avertissement, efface la page endommagée en mémoire et continue son traitement. Ce comportement détruit des données, très exactement toutes les lignes comprises dans la page endommagée. Néanmoins, il vous permet de passer l'erreur et de récupérer les lignes des pages non endommagées qui pourraient être présentes dans la table. C'est intéressant pour récupérer des données si une corruption est survenue à cause d'une erreur logicielle ou matérielle. Vous ne devriez pas activer cette option sauf si vous avez perdu tout espoir de récupérer les données des pages endommagées d'une table. L'effacement des pages n'est pas vidée sur disque donc il est recommandé de recréer la table ou l'index avant de désactiver de nouveau ce paramètre. La configuration par défaut est off, et peut seulement être modifiée par un superutilisateur ou par un utilisateur disposant des droits SET adéquats.

Si configuré à off (la valeur par défaut), la détection d'enregistrements de journaux de transactions ayant des références à des pages invalides lors de la restauration fait que PostgreSQL lève une erreur de niveau PANIC, annulant la restauration. Configurer ignore_invalid_pages à on fait que le système ignore les références invalides de page dans les enregistrements des journaux de transactions (tout en renvoyant malgré tout un message d'avertissement) et continue la restauration. Ce comportement peut causer des crashs, des pertes de données, propager ou cacher la corruption, ainsi que différents autres problèmes sérieux. Néanmoins, il peut vous permettre de passer l'erreur de niveau PANIC pour finir la restauration, et permettre ainsi au serveur de démarrer. Ce paramètre peut seulement être configuré au démarrage du serveur. Il a seulement un effet lors de la restauration et dans le mode standby.

Si LLVM en est capable, enregistre les fonctions générées auprès de GDB. Cela facilite le débogage. Le paramètrage par défaut est off. Ce paramètre peut seulement être configuré au démarrage du serveur.

Écrit l'IR (intermediate representation) de LLVM dans le système de fichiers, dans data_directory. Ce n'est utile que pour travailler sur le fonctionnement interne de l'implémentation JIT. Le défaut est off. Seuls les superutilisateurs et les utilisateurs disposant des droits SET adéquats peuvent modifier ce paramètre.

Détermine si les expressions sont compilées par JIT quand la compilation JIT est activée (voir Section 30.2). La valeur par défaut est on.

Si LLVM le peut, pour que perf puisse profiler les fonctions générées par le JIT, écrit les données nécessaires dans des fichiers dans $HOME/.debug/jit/  ; l'utilisateur est responsable du nettoyage en temps voulu. Le paramétrage par défaut est off,. Il ne peut être mis en place qu'au démarrage du serveur.

Détermine si le décodage d'enregistrement est compilé par le JIT, quand la compilation JIT est activée (voir Section 30.2). Le défaut est on.

Quand initialisé à on, qui est la valeur par défaut, PostgreSQL va supprimer automatiquement les fichiers temporaires après un crash. Si désactivé, les fichiers vont rester et peuvent être utilisés pour le débogage, par exemple. De nombreux crashs peuvent mener cependant à l'accumulation de fichiers inutiles.

Par défaut, après un crash d'un backend, le postmaster terminera tous les processus enfants restant en leur envoyant un signal SIGQUIT, ce qui leur permettra de sortir plus ou moins gracieusement. Quand cette option est définie sur on, SIGABRT est envoyé à la place. Cela entraîne normalement la production d'un fichier de vidage mémoire pour chacun de ses enfants processus. Cela peut être pratique pour étudier les états d'autres processus après un accident. Cela peut également consommer beaucoup d'espace disque en cas de plantages répétés, n'activez cette option que sur des systèmes que vous surveillez attentivement. Attention, aucun support n'existe pour nettoyer les fichiers automatiquement. Ce paramètre ne peut être défini que dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Par défaut, après avoir tenté d'arrêter un processus enfant avec SIGQUIT, le postmaster attendra cinq secondes puis enverra SIGKILL pour forcer la terminaison immédiate. Lorsque cette option est définie à on, SIGABRT est envoyé au lieu de SIGKILL. Cela entraîne normalement la production d'un fichier de vidage mémoire pour chacun de ses enfants processus. Cela peut être pratique pour étudier les états d'autres processus après un accident. Cela peut également consommer beaucoup d'espace disque en cas de plantages répétés, n'activez cette option que sur des systèmes que vous surveillez attentivement. Attention, aucun support n'existe pour nettoyer les fichiers automatiquement. Ce paramètre ne peut être défini que dans le fichier postgresql.conf ou sur la ligne de commande du serveur.

Les valeurs autorisées sont buffered et immediate. La valeur par défaut est buffered. Ce paramètre est destiné à être utilisé pour tester le décodage logique et la réplication de larges transactions. L'effet de debug_logical_replication_streaming est différent pour un publieur et un abonné :

Du côté du publieur, debug_logical_replication_streaming permet de diffuser ou de sérialiser les modifications immédiatement lors du décodage logique. Lorsqu'il est défini sur immediate, il diffuse chaque modification si l'option streaming de CREATE SUBSCRIPTION est activée, sinon, il sérialisera chaque modification. Lorsqu'il est réglé sur buffered, le décodage ou la sérialisation sera faite lorsque logical_decoding_work_mem est atteint.

Côté abonné, si l'option streaming est définie sur parallel, debug_logical_replication_streaming peut être utilisé pour demander au worker maitre d'envoyer les modifications dans les files d'attente de la mémoire partagée ou de sérialiser toutes les modifications apportées dans un fichier. Lorsqu'il est réglé sur buffered, le worker maitre envoie les modifications aux workers parallèles via une file d'attente de la mémoire partagée. Lorsqu'il est réglé sur immediate, le worker maitre sérialise toutes les modifications apportées aux fichiers et informe les workers parallèles de les lire et de les appliquer à la fin de la transaction.