Les paramètres qui suivent permettent de travailler sur les sources de PostgreSQL™ et, dans certains cas, fournissent une aide à la récupération de bases de données sévèrement endommagées. Il n'y a aucune raison de les utiliser en configuration de production. 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.
Autorise la modification de la structure des tables systèmes. Ce paramètre, utilisé par initdb, n'est modifiable qu'au démarrage du serveur.
Active différentes vérifications d'affectations. C'est une aide au débogage. En cas de problèmes étranges ou d'arrêts brutaux, ce paramètre peut être activé car il permet de remonter des erreurs de programmation. Pour utiliser ce paramètre, la macro USE_ASSERT_CHECKING doit être définie lors de la construction de PostgreSQL™ (à l'aide de l'option --enable-cassert de configure). Ce paramètre est activé par défaut si PostgreSQL™ a été construit avec l'activation des assertions.
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.
Si ce paramètre est différent de zéro, un délai de ce nombre de secondes intervient, après l'étape d'authentification, lorsqu'un nouveau processus serveur est lancé. Ceci a pour but de donner l'opportunité d'attacher un débogueur au processus serveur. Ce paramètre ne peut pas être modifié après le démarrage de la session.
Si ce paramètre est différent de zéro, un délai de ce nombre de secondes intervient juste après la création d'un nouveau processus, 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. 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 un DeadLockTimeout (expiration de temps d'attente de 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 btree.
Ce paramètre n'est disponible que si la macro BTREE_BUILD_STATS a été définie quand PostgreSQL™ a été compilé.
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™.
La détection d'une en-tête de page endommagée cause généralement le rapport d'une erreur par PostgreSQL™ et l'annulation de la commande courante. Initialiser zero_damaged_pages à on oblige le système à remonter un avertissement, à vider la page endommagée et à continuer le traitement. Ce comportement détruit les données (à savoir, toutes les lignes de la page endommagée). Mais cela permet de passer outre l'erreur et de récupérer les lignes des pages non endommagées qui peuvent être présentes dans la table. Ce paramètre s'avère donc utile pour récupérer les données si la corruption est due à une erreur matérielle ou logicielle. Il est généralement préférable de ne pas configurer ce paramètre à on, sauf à abandonner l'espoir de récupérer les données des pages endommagées d'une table. Par défaut ce paramètre est désactivé. Seul un superutilisateur peut modifier cette configuration.
Options personnalisées
