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.
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.
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.
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.
Si actif, émet des informations sur l'utilisation des ressources lors des opérations de tri. Cette option est seulement disponible si la macro TRACE_SORT était définie lorsque PostgreSQL™ a été compilé (néanmoins, TRACE_SORT est actuellement définie par défaut).
Différentes autres options de trace et de débogage.
Si on, émet une sortie de débogage relative aux WAL. Cette option est seulement disponible si la macro WAL_DEBUG était 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™, l'annulation de la commande courante. Initialiser zero_damaged_pages à on 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, c'est-à-dire 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 à on 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.
Options personnalisées