17.7. Rapports d'erreur et traces

PostgreSQL™ supporte plusieurs méthodes pour la journalisation des messages du serveur, dont stderr et syslog. Sur Windows, eventlog est aussi supporté. Configurez cette option avec une liste de destinations désirées pour les journaux, séparées par des virgules. Par défaut, les traces vont seulement sur stderr. Cette option est disponible au lancement du serveur et dans le fichier de configuration de postgresql.conf.

Cette option autorise la capture et la redirection des messages envoyés vers stderr dans des journaux de traces. Cette option, en combinaison avec les traces stderr, est souvent plus utile que de tracer dans syslog car certains types de messages pourraient ne pas apparaître dans la sortie syslog (un exemple habituel concerne les messages d'échecs de l'éditeur de liens). Cette option est seulement disponible au lancement du serveur.

Quand redirect_stderr est activé, cette option détermine le répertoire dans lequel les fichiers de trace sont créés. Elle pourrait être spécifiée avec un chemin absolu ou relatif au répertoire des données du groupe. Cette option est disponible au lancement du serveur et dans le fichier postgresql.conf.

Quand redirect_stderr est activé, cette option initialise les noms des fichiers des journaux créés. La valeur est traitée comme un modèle strftime, du coup les échappements % peuvent être utilisés pour spécifier des noms de fichiers dépendant de l'heure. Si aucun échappement % n'est présent, PostgreSQL™ ajoutera l'époque de l'heure d'ouverture du nouveau journal. Par exemple, si log_filename valait server_log, alors le nom de fichier choisi serait server_log.1093827753 pour un journal commençant le dimanche 29 août 19:02:33 2004 MST. Cette option est disponible au lancement du serveur et dans le fichier de configuration postgresql.conf.

Quand redirect_stderr est activé, cette option détermine la durée de vie maximum d'un journal individuel. Après que cette durée se soit écoulée, un nouveau journal est créé. Initialisez-la à zéro pour désactiver la création des nouveaux journaux suivant un délai. Cette option est disponible au lancement du serveur et dans le fichier de configuration postgresql.conf.

Quand redirect_stderr est activé, cette option détermine la taille maximum d'un journal individuel. Après ce nombre d'octets, un nouveau journal est créé. Initialiser cette taille à zéro désactive la création de nouveaux journaux suivant leur taille. Cette option est disponible au lancement du serveur et dans le fichier de configuration postgresql.conf.

Quand redirect_stderr est activé, cette option fera que PostgreSQL™ tronque (surcharge), plutôt qu'il n'ajoute à un journal de même nom. Néanmoins, ce tronquage ne surviendra qu'à partir du moment où un nouveau fichier sera ouvert à cause d'une rotation basée sur le temps, et non pas suite au lancement du serveur ou suite à une rotation basée sur la taille. Si désactivé (off), les fichiers déjà existants se verront ajoutés les nouvelles traces dans tous les cas. Par exemple, en utilisant cette option en combinaison avec un log_filename comme postgresql-%H.log résulterait en la génération de 24 journaux (un pour chaque heure) puis les surchargera cycliquement. Cette option est disponible au lancement du serveur et dans le fichier de configuration postgresql.conf.

Exemple : pour conserver sept jours de traces, un fichier par jour nommé server_log.Mon, server_log.Tue, etc. et surcharger automatiquement les traces de la semaine dernière avec ceux de cette semaine, configurez log_filename à server_log.%a, log_truncate_on_rotation à on et log_rotation_age à 1440.

Exemple : pour conserver 24 heures de traces, un journal par heure mais aussi, faire une rotation plus souvent si le journal dépasse 1 Go, configurez log_filename à server_log.%H%M, log_truncate_on_rotation à on, log_rotation_age à 60 et log_rotation_size à 1000000. Inclure %M dans log_filename permet des rotations conduites par la taille qui pourraient survenir pour sélectionner un nom de fichier différent du nom de fichier initial.

Lorsque les traces syslog sont activées, cette option détermine le niveau (« facility ») utilisé par syslog. Vous pouvez choisir entre LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7 ; la valeur par défaut est LOCAL0. Voir aussi la documentation du démon syslog de votre serveur. Cette option se configure au lancement du système et dans le fichier de configuration postgresql.conf.

Si syslog est activé, cette option détermine le nom du programme utilisé pour identifier les messages de PostgreSQL™ dans les journaux de traces de syslog. La valeur par défaut est postgres. Cette option se configure au lancement du système et dans le fichier de configuration postgresql.conf.

Contrôle les niveaux des messages envoyés au client. Les valeurs valides peuvent être DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR, FATAL, et PANIC. Chaque niveau inclut tous les niveaux qui le suivent. La valeur par défaut est NOTICE. Notez que LOG a un niveau différent que dans log_min_messages.

Contrôle les niveaux des messages écrits dans les journaux de traces. Les valeurs valides sont DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL et PANIC. Chaque niveau inclut tous les niveaux qui le suivent. Le niveau le plus bas obtient le plus petit nombre de messages. La valeur par défaut est NOTICE. Notez que LOG a un niveau différent que dans client_min_messages. Seuls les superutilisateurs peuvent modifier ce paramétrage.

Contrôle le nombre de détails écrits dans les journaux de traces pour chaque message tracé. Les valeurs valides sont TERSE, DEFAULT et VERBOSE, chacune ajoutant plus de champs aux messages affichés. Seuls les superutilisateurs peuvent modifier ce paramétrage.

Contrôle si l'instruction SQL ayant causé une erreur sera aussi enregistrée dans le journal des traces. Toutes les instructions SQL, qui causent une erreur du niveau spécifié ou d'un niveau plus haut, seront tracées. La valeur par défaut est PANIC (désactivant réellement cette fonctionnalité en production). Les valeurs valides sont DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, FATAL et PANIC. Par exemple, si vous l'initialisez à ERROR, alors toutes les instructions SQL causant des erreurs, fatales ou non, ou des paniques seront tracées. Activer cette option est utile pour localiser la source de toute erreur apparaissant dans le journal des traces. Seuls les superutilisateurs peuvent modifier ce paramétrage.

Trace l'instruction et sa durée sur une seule ligne de trace si son exécution dure au moins ce nombre de millisecondes. Configurer cette valeur à zéro affichera toutes les instructions avec leur durées. -1 (la valeur par défaut) désactive cette fonctionnalité. Par exemple, si vous la configurez à 250, alors toutes les instructions SQL s'exécutant en 250ms ou en plus de temps seront tracées. Activer cette option peut être utile pour traquer les requêtes non optimisées dans vos applications. Ce paramètre est indépendant de log_statement et log_duration. Seuls les superutilisateurs peuvent modifier ce paramètre.

Exécute le serveur silencieusement. Si cette option est configurée, le serveur se lancera automatiquement en tâche de fond et tout terminal de contrôle sera dissocié (même effet que l'option -S de postmaster). La sortie standard et la sortie standard des erreurs du serveur sont redirigées vers /dev/null, donc tout message qui leur est adressé sera perdu. Sauf si le journal syslog est sélectionné ou que redirect_stderr est activé, utiliser cette option n'est pas encouragé car il empêche de voir les messages d'erreurs.

Fournit des informations utiles aux développeurs.

Fournit des informations implicitement demandées par l'utilisateur, par exemple lors d'un VACUUM VERBOSE.

Fournit des informations qui pourraient être utiles aux utilisateurs, par exemple lors du tronquage d'identifiants longs ou la création d'index faisant partie de clés primaires.

Fournit des avertissements aux utilisateurs, par exemple un COMMIT en dehors d'un bloc de transactions.

Rapporte une erreur qui a annulé la commande en cours.

Rapporte des informations intéressant les administrateurs, par exemple l'activité des points de vérification.

Rapporte une erreur qui a causé l'annulation de la session courante.

Rapporte une erreur qui a causé l'annulation de toutes les sessions.

Ces options activent plusieurs sorties de débogage. Pour chaque requête exécutée, elles affichent l'arbre d'analyse résultant. debug_pretty_print indente ces affichages pour produire un format de sortie plus lisible mais plus long. client_min_messages ou log_min_messages doivent valoir DEBUG1 ou plus bas pour réellement envoyer cette sortie vers le client ou les traces du serveur, respectivement. Ces options sont désactivées par défaut.

Ceci affiche une ligne dans les traces du serveur détaillant chaque connexion réussie. Désactivée par défaut, elle est probablement très utile. Certains programmes client, comme psql, tentent de se connecter deux fois pour déterminer si un mot de passe est requis, donc des messages « connection received » dupliqués n'indiquent pas nécessairement un problème. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.

Ceci affiche dans les journaux du serveur une ligne similaire à log_connections mais à la fin d'une session et inclut la durée de la session. Elle est désactivée par défaut. Ce paramètre peut seulement être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.

Fait que la durée d'une instruction terminée satisfaisant log_statement est tracée. En utilisant cette option, si vous n'utilisez pas syslog, il est recommandé que vous traciez le PID ou l'ID de la session en utilisant log_line_prefix, de façon à ce que vous puissiez lier le message instruction au prochain message sur la durée en utilisant l'ID du processus ou de la session. Cette variable est désactivée par défaut. Seuls les superutilisateurs peuvent modifier ce paramétrage.

Ceci est une chaîne style printf qui est affichée au début de chaque ligne de trace. La valeur par défaut est une chaîne vide. Chaque échappement reconnu est remplacé comme indiqué ci-dessous - tout ce qui reste et qui ressemble à un échappement est ignoré. Les autres caractères sont copiés directement sur la ligne. Certains échappements sont seulement reconnus par les processus de session et ne s'appliquent pas aux processus en tâche de fond comme le postmaster. Syslog produit son propre marquage horaire et informations d'ID sur le processus, donc vous ne voudrez probablement pas utiliser ces échappements si vous utilisez syslog. Cette option est disponible au lancement du serveur et dans le fichier de configuration postgresql.conf.

Contrôle les instructions SQL tracées. Les valeurs valides sont none, ddl, mod et all. ddl trace toutes les commandes de définition comme CREATE, ALTER et DROP. mod trace toutes les instructions ddl, plus INSERT, UPDATE, DELETE, TRUNCATE et COPY FROM. Les instructions PREPARE et EXPLAIN ANALYZE sont aussi tracées si leur commande contenue est d'un type approprié.

La valeur par défaut est none. Seuls les superutilisateurs peuvent changer ce paramétrage.

Note

L'instruction EXECUTE n'est pas considérée comme une instruction ddl ou mod. Les instructions qui génèrent des erreurs de syntaxe ne sont pas tracées. Pour cela, initialisez l'option log_min_error_statement à error.

Quand une fonction est définie dans le langage côté serveur PL/pgSQL, toute requête exécutée par la fonction sera seulement tracée la première fois que la fonction est appelée d'une session particulière. Ceci est dû au fait que PL/pgSQL conserve un cache des plans de requête produits par les instructions SQL dans la fonction.

Par défaut, les messages de traces de connexion affichent seulement l'adresse IP de l'hôte se connectant. Activer cette option causera la trace du nom de l'hôte. Notez que, suivant votre configuration de résolution de nom d'hôte, ceci pourrait imposer une pénalité de performance non négligeable. Cette option est disponible au lancement du serveur et dans le fichier postgresql.conf.