PostgreSQL™ supporte plusieurs méthodes pour la journalisation des messages du serveur, dont stderr et syslog. Sur Windows, eventlog est aussi supporté. Ce paramètre se configure avec la liste des destinations souhaitées séparées par des virgules. Par défaut, les traces ne sont dirigées que vers stderr. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Ce paramètre permet de capturer les messages envoyés vers stderr et de les diriger dans des journaux de traces. Combinée aux traces stderr, cette méthode est souvent plus utile que de tracer dans syslog car certains types de messages peuvent ne pas apparaître dans la sortie syslog (un exemple habituel concerne les messages d'échecs de l'éditeur de liens). Ce paramètre ne peut être positionné qu'au démarrage du serveur.
Lorsque redirect_stderr est activé, ce paramètre détermine le répertoire dans lequel les fichiers de trace sont créés. Il peut s'agir d'un chemin absolu ou d'un chemin relatif au répertoire des données du cluster. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Lorsque redirect_stderr est activé, ce paramètre indique les noms des fichiers des journaux créés. La valeur est traitée comme un motif strftime. Ainsi les échappements % peuvent être utilisés pour indiquer des noms de fichiers horodatés. Si aucun échappement % n'est présent, PostgreSQL™ ajoute l'époque ( epoch ) d'ouverture du nouveau journal. Par exemple, si log_filename vaut server_log, alors le nom de fichier est server_log.1093827753 pour un journal commençant le dimanche 29 août à 19:02:33 2004 MST. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Lorsque redirect_stderr est activé, ce paramètre détermine la durée de vie maximale (en minutes) d'un journal individuel. Passé ce délai, un nouveau journal est créé. Initialiser ce paramètre à zéro désactive la création en temps compté de nouveaux journaux. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Lorsque redirect_stderr est activé, ce paramètre détermine la taille maximale (en kilooctets) d'un journal individuel. Passé cette taille, un nouveau journal est créé. Initialiser cette taille à zéro désactive la création en taille comptée de nouveaux journaux. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Lorsque redirect_stderr est activé, ce paramètre impose à PostgreSQL™ de tronquer (surcharger), plutôt qu'ajouter à, tout fichier journal dont le nom existe déjà. Toutefois, ce surchargement ne survient qu'à partir du moment où un nouveau fichier doit être ouvert du fait d'une rotation par temps compté, et non pas à la suite du démarrage du serveur ou d'une rotation par taille comptée. Si ce paramètre est désactivé (off), les traces sont, dans tous les cas ajoutées aux fichiers qui existent déjà.
Par exemple, si ce paramètres est utilisé en combinaison avec un log_filename tel que postgresql-%H.log, il en résulte la génération de 24 journaux (un par heure) écrasés de façon cyclique.
Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
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 précédente avec celles de la semaine courante, on positionne 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, toute en effectuant la rotation plus tôt si le journal dépasse 1 Go, on positionne 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 à toute rotation par taille comptée qui survient d'utiliser un nom de fichier distinct du nom initial horodaté.
Lorsque les traces syslog sont activées, ce paramètre fixe le niveau (« facility ») utilisé par syslog. Les différentes possibilités sont LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7 ; LOCAL0 étant la valeur par défaut. Voir aussi la documentation du démon syslog du serveur. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Si syslog est activé, ce paramètre fixe le nom du programme utilisé pour identifier les messages PostgreSQL™ dans les traces de syslog. La valeur par défaut est postgres. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Contrôle les niveaux de message envoyés au client. Les valeurs valides sont DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING, ERROR, FATAL, et PANIC. Chaque niveau inclut tous les niveaux qui le suivent. Plus on progresse dans la liste, plus le nombre de messages envoyés est faible. NOTICE est la valeur par défaut. LOG a ici une portée différente à celle de log_min_messages.
Contrôle les niveaux de message écrits dans les traces du serveur. 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. Plus on progresse dans la liste, plus le nombre de messages envoyés est faible. NOTICE est la valeur par défaut. LOG a ici une portée différente à celle de client_min_messages. Seuls les superutilisateurs peuvent modifier la valeur de ce paramètre.
Contrôle le niveau de détail des traces de chaque message. 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 à l'origine d'une une erreur doit être enregistrée dans les traces du serveur. L'instruction SQL en cours est incluse dans les traces pour tout message de sévérité indiquée ou supérieure. Les valeurs valides sont DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, FATAL et PANIC. ERROR est la valeur par défaut, ce qui signifie que les instructions à l'origine d'erreurs, d'erreurs fatales ou de paniques sont tracées. Pour réellement désactiver le traçage des instructions échouées, ce paramètre doit être positionné à PANIC. Seuls les superutilisateurs peuvent modifier la valeur de ce paramètre.
Trace la durée de toute instruction terminée dont le temps d'exécution égale ou dépasse ce nombre de millisecondes. Positionné à zéro, les durées de toutes les instructions sont tracées. -1 (valeur par défaut) désactive ces traces.
Par exemple, si le paramètre est positionné à 250ms, alors toutes les instructions SQL dont la durée est supérieure ou égale à 250 ms sont tracées.
Il est utile d'activer ce paramètre pour tracer les requêtes non optimisées des applications. Seuls les superutilisateurs peuvent modifier cette configuration.
Pour les clients utilisant le protocole de requêtage étendu, les durées des étapes Parse (analyse), Bind (lien) et Execute (exécution) sont tracées indépendamment.
![[Note]](images/note.png)
Lorsque cette option est utilisée avec log_statement, le texte des instructions tracées du fait de log_statement n'est pas répété dans le message de trace de la durée. Si syslog n'est pas utilisé, il est recommandé de tracer le PID ou l'ID de session à l'aide de log_line_prefix de façon à pouvoir lier le message de l'instruction au message de durée par cet ID.
Exécute le serveur silencieusement. Si ce paramètre est configuré, le serveur démarre automatiquement en tâche de fond et tout terminal de contrôle est dissocié. La sortie standard et l'erreur standard sont redirigées vers /dev/null, donc tout message qui leur est adressé est perdu. À moins que syslog ne soit sélectionné ou que redirect_stderr soit activé, l'utilisation de ce paramètre est fortement déconseillé car il empêche de voir les messages d'erreurs. Ce paramètre ne peut être configuré qu'au démarrage du serveur.
Liste des niveaux de sévérité des messages utilisés pour ces paramètres :
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 éventuellement utiles aux utilisateurs, par exemple lors de la troncature d'identifiants longs ou la création d'index 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 causé l'annulation de 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 en cours.
Rapporte une erreur qui a causé l'annulation de toutes les sessions.
Ces paramètres 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 au maximum DEBUG1 pour que cette sortie soit effectivement envoyée vers le client ou les traces du serveur, respectivement. Ces paramètres sont désactivés par défaut.
Affiche une ligne dans les traces du serveur détaillant chaque connexion réussie. Bien que désactivé par défaut, ce paramètre 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 ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Affiche dans les traces du serveur une ligne similaire à log_connections mais à la fin d'une session, en incluant la durée de la session. Désactivé par défaut, ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Trace la durée de toute instruction exécutée. Désactivé par défaut (off), seuls les superutilisateurs peuvent modifier ce paramètre.
Pour les clients utilisant le protocole de requêtage étendu, les durées des étapes Parse (analyse), Bind (lien) et Execute (exécution) sont tracées indépendamment.
À la différence de log_min_duration_statement, ce paramètre ne force pas le traçage du texte des requêtes. De ce fait, si log_duration est activé (on) et que log_min_duration_statement a une valeur positive, toutes les durées sont tracées mais le texte de la requête n'est inclus que pour les instructions qui dépassent la limite. Ce comportement peut être utile pour récupérer des statistiques sur les installations à forte charge.
Chaîne de style printf 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 ne sont reconnus que par les processus de session et ne s'appliquent pas aux processus en tâche de fond comme le processus serveur principal. Syslog produit ses propres estampilles temporelles et informations d'ID de processus. Il n'est donc pas forcément utile d'utiliser ces échappements avec syslog. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
| Échappement | Produit | Session seulement |
|---|---|---|
| %u | Nom de l'utilisateur | oui |
| %d | Nom de la base de données | oui |
| %r | Nom ou adresse IP de l'hôte distant et port distant | oui |
| %h | Nom d'hôte distant ou adresse IP | yes |
| %p | ID du processus | non |
| %t | Estampille temporelle (sans milliseconde, pas de fuseau horaire sous Windows) | non |
| %m | Estampille temporelle avec millisecondes | non |
| %i | Balise de commande : la commande qui a engendré la trace. | oui |
| %c | ID de session : un identifiant unique pour chaque session. Il s'agit de deux numéros hexadécimaux sur quatre octets (sans zéro initial) séparés par un point. Les nombres représentent l'heure de début de session et l'ID de son processus. C'est un moyen concis d'écrire ces éléments. | oui |
| %l | Numéro de la ligne de trace de chaque processus, commençant à 1 | non |
| %s | Estampille temporelle du début de session | oui |
| %x | ID de la transaction | oui |
| %q | Ne produit aucune sortie, mais indique aux autres processus de stopper à cet endroit de la chaîne. Ignoré par les processus de session. | non |
| %% | % | non |
Contrôle les instructions SQL à tracer. 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 ainsi que les instructions de modification de données INSERT , UPDATE , DELETE , TRUNCATE et COPY FROM . Les instructions PREPARE , EXECUTE et EXPLAIN ANALYZE sont aussi tracées si la commande qui les contient est d'un type approprié. Pour les clients utilisant le protocole de requêtage étendu, la trace survient quand un message Execute est reçu et les valeurs des paramètres de Bind sont incluses (avec doublement de tout guillemet simple embarqué).
La valeur par défaut est none. Seuls les superutilisateurs peuvent changer ce paramétrage.
Les instructions qui contiennent de simples erreurs de syntaxe ne sont pas tracées même si log_statement est positionné à all car la trace n'est émise qu'après qu'une analyse basique soit réalisée pour déterminer le type d'instruction. Dans le cas du protocole de requêtage étendu, ce paramètre ne trace pas les instructions qui échoue avant la phase Execute (c'est-à-dire pendant l'analyse et la planification). log_min_error_statement doit être positionné à ERROR pour tracer ce type d'instructions.
Par défaut, les messages de traces de connexion n'affichent que l'adresse IP de l'hôte d'où émane la tentative de connexion. L'activation de ce paramètre permet de tracer également le nom de l'hôte. En fonction de la configuration de la résolution de nom d'hôte, ceci peut entraîner une baisse de performance non négligeable. Ce paramètre ne peut qu'être configuré dans le fichier postgresql.conf ou indiqué sur la ligne de commande.
Planification des requêtes
