Les paramètres qui suivent ont été développés à des fins de test et ne
doivent pas être utilisés sur une base de production. Cependant, certains
d'entre eux peuvent aider à restaurer des bases de données corrompues. En
tant que tel, ils sont exclus du fichier d'exemple de
postgresql.conf
. Un certain nombre d'entre eux
requièrent des options de compilation spéciales pour fonctionner.
allow_in_place_tablespaces
(boolean
)
#
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.
allow_system_table_mods
(boolean
) #
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.
backtrace_functions
(string
)
#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.
debug_discard_caches
(integer
)
#
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.
debug_io_direct
(string
)
#
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.
debug_parallel_query
(enum
)
#
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_system_indexes
(boolean
) #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.
post_auth_delay
(integer
) #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.
pre_auth_delay
(integer
) #
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.
trace_notify
(boolean
) #
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.
trace_recovery_messages
(enum
) #
Contrôle les niveaux des traces écrites dans le journal applicatif
pour les modules nécessaires lors du traitement de la restauration.
Cela permet à l'utilisateur de surcharger la configuration normale
de log_min_messages, mais seulement pour des
messages spécifiques. Ça a été ajouté principalement pour débugger Hot
Standby. Les valeurs valides sont DEBUG5
,
DEBUG4
, DEBUG3
,
DEBUG2
, DEBUG1
et
LOG
. La valeur par défaut, LOG
,
n'affecte pas les décisions de trace. Les autres valeurs causent
l'apparition de messages de débogage relatifs à la restauration pour
tous les messages de ce niveau et des niveaux supérieurs. Elles utilisent
malgré tout le niveau LOG
; pour les
configurations habituelles de log_min_messages
, cela
résulte en un envoi sans condition dans les traces du serveur.
Ce paramètre ne peut être configuré que dans le fichier
postgresql.conf
ou indiqué sur la ligne de commande.
trace_sort
(boolean
) #
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).
trace_locks
(boolean
) #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é.
trace_lwlocks
(boolean
) #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é.
trace_userlocks
(boolean
) #
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.
trace_lock_oidmin
(integer
) #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é.
trace_lock_table
(integer
) #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é.
debug_deadlocks
(boolean
) #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é.
log_btree_build_stats
(boolean
) #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é.
wal_consistency_checking
(string
)
#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.
wal_debug
(boolean
) #
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.
ignore_checksum_failure
(boolean
) #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.
zero_damaged_pages
(boolean
) #
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.
ignore_invalid_pages
(boolean
)
#
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.
jit_debugging_support
(boolean
)
#
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.
jit_dump_bitcode
(boolean
)
#
É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.
jit_expressions
(boolean
)
#
Détermine si les expressions sont compilées par JIT quand la
compilation JIT est activée (voir Section 32.2). La
valeur par défaut est on
.
jit_profiling_support
(boolean
)
#
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.
jit_tuple_deforming
(boolean
)
#
Détermine si le décodage d'enregistrement est compilé par le JIT,
quand la compilation JIT est activée (voir Section 32.2). Le défaut est on
.
remove_temp_files_after_crash
(boolean
)
#
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.
send_abort_for_crash
(boolean
)
#
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.
send_abort_for_kill
(boolean
)
#
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.
debug_logical_replication_streaming
(enum
)
#
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.