Lorsque vous trouvez un bogue dans PostgreSQL, nous voulons en entendre parler. Vos rapports de bogues jouent un rôle important pour rendre PostgreSQL plus fiable, car même avec la plus grande attention, nous ne pouvons pas garantir que chaque partie de PostgreSQL fonctionnera sur toutes les plates-formes et dans toutes les circonstances.
Les suggestions suivantes ont pour but de vous former à la saisie d'un rapport de bogue qui pourra ensuite être géré de façon efficace. Il n'est pas requis de les suivre, mais ce serait à l'avantage de tous.
Nous ne pouvons pas promettre de corriger tous les bogues immédiatement. Si le bogue est évident, critique ou affecte un grand nombre d'utilisateurs, il y a de grandes chances pour que quelqu'un s'en charge. Il se peut que nous vous demandions d'utiliser une version plus récente pour vérifier si le bogue est toujours présent. Ou nous pourrions décider que le bogue ne peut être corrigé avant qu'une réécriture massive, que nous avions planifiée, ne soit faite. Ou peut-être est-ce trop difficile et que des choses plus importantes nous attendent. Si vous avez besoin d'aide immédiatement, envisagez l'obtention d'un contrat de support commercial.
Avant de rapporter un bogue, merci de lire et relire la documentation pour vérifier que vous pouvez réellement faire ce que vous essayez de faire. Si ce n'est pas clair, rapportez-le aussi ; c'est un bogue dans la documentation. S'il s'avère que le programme fait différemment de ce qu'indique la documentation, c'est un bogue. Ceci peut inclure les circonstances suivantes, sans s'y limiter :
Un programme se terminant avec un signal fatal ou un message d'erreur du système d'exploitation qui indiquerait un problème avec le programme. (Un contre-exemple pourrait être le message « disk full », disque plein, car vous devez le régler vous-même.)
Un programme produit une mauvaise sortie pour une entrée donnée.
Un programme refuse d'accepter une entrée valide (c'est-à-dire telle que définie dans la documentation).
Un programme accepte une entrée invalide sans information ou message d'erreur. Mais gardez en tête que votre idée d'entrée invalide pourrait être notre idée d'une extension ou d'une compatibilité avec les pratiques traditionnelles.
PostgreSQL échoue à la compilation, à la construction ou à l'installation suivant les instructions des plates-formes supportées.
Ici, « programme » fait référence à un exécutable, pas au moteur du serveur.
Une lenteur ou une absorption des ressources n'est pas nécessairement un bogue. Lisez la documentation ou demandez sur une des listes de discussion de l'aide concernant l'optimisation de vos applications. Ne pas se conformer au standard SQL n'est pas nécessairement un bogue, sauf si une telle conformité est indiquée explicitement.
Avant de continuer, vérifiez sur la liste des choses à faire ainsi que dans la FAQ pour voir si votre bogue n'est pas déjà connu. Si vous n'arrivez pas à décoder les informations sur la liste des choses à faire, écrivez un rapport. Le minimum que nous puissions faire est de rendre cette liste plus claire.
Le point le plus important à se rappeler avec les rapports de bogues est de donner tous les faits et seulement les faits. Ne spéculez pas sur ce que vous pensez qui ne va pas, sur ce qu'« il semble faire » ou sur quelle partie le programme a une erreur. Si vous n'êtes pas familier avec l'implémentation, vous vous tromperez probablement et vous ne nous aiderez pas. Et même si vous avez raison, des explications complètes sont un bon supplément, mais elles ne doivent pas se substituer aux faits. Si nous pensons corriger le bogue, nous devons toujours le reproduire nous-mêmes. Rapporter les faits stricts est relativement simple (vous pouvez probablement copier/coller à partir de l'écran) mais, trop souvent, des détails importants sont oubliés parce que quelqu'un a pensé qu'ils n'avaient pas d'importance ou que le rapport serait compris.
Les éléments suivants devraient être fournis avec chaque rapport de bogue :
La séquence exacte des étapes nécessaires pour reproduire le problème
à partir du lancement du programme. Ceci devrait se
suffire ; il n'est pas suffisant d'envoyer une simple instruction
SELECT sans les commandes CREATE
TABLE et INSERT qui ont précédé, si la
sortie devait dépendre des données contenues dans les tables. Nous
n'avons pas le temps de comprendre le schéma de votre base de données. Si
nous sommes supposés créer nos propres données, nous allons probablement
ne pas voir le problème.
Le meilleur format pour un test suite à un problème relatif à SQL est un
fichier qui peut être lancé via l'interface
psql et qui montrera le problème.
(Assurez-vous de ne rien avoir dans votre fichier de lancement
~/.psqlrc.) Un moyen facile pour créer ce fichier
est d'utiliser pg_dump pour récupérer les
déclarations des tables ainsi que les données nécessaires pour mettre en
place la scène. Il ne reste plus qu'à ajouter la requête posant problème.
Vous êtes encouragé à minimiser la taille de votre exemple, mais ce n'est
pas une obligation. Si le bogue est reproductible, nous le trouverons de
toute façon.
Si votre application utilise une autre interface client, telle que PHP, alors essayez d'isoler le problème aux requêtes erronées. Nous n'allons certainement pas mettre en place un serveur web pour reproduire votre problème. Dans tous les cas, rappelez-vous d'apporter les fichiers d'entrée exacts ; n'essayez pas de deviner que le problème se pose pour les « gros fichiers », pour les « bases de données de moyenne taille », etc., car cette information est trop inexacte, subjective pour être utile.
La sortie que vous obtenez. Merci de ne pas dire que cela « ne fonctionne pas » ou s'est « arrêté brutalement ». S'il existe un message d'erreur, montrez-le même si vous ne le comprenez pas. Si le programme se termine avec une erreur du système d'exploitation, dites-le. Même si le résultat de votre test est un arrêt brutal du programme ou un autre souci évident, il pourrait ne pas survenir sur notre plateforme. Le plus simple est de copier directement la sortie du terminal, si possible.
Si vous rapportez un message d'erreur, merci d'obtenir la forme la plus
verbeuse de ce message. Avec psql, exécutez
\set VERBOSITY verbose avant tout. Si vous récupérez
le message des traces du serveur, initialisez la variable d'exécution
log_error_verbosity avec verbose
pour que tous les détails soient tracés.
Dans le cas d'erreurs fatales, le message d'erreur rapporté par le client pourrait ne pas contenir toutes les informations disponibles. Jetez aussi un œil aux traces du serveur de la base de données. Si vous ne conservez pas les traces de votre serveur, c'est le bon moment pour commencer à le faire.
Il est très important de préciser ce que vous attendez en sortie. Si vous écrivez uniquement « Cette commande m'a donné cette réponse. » ou « Ce n'est pas ce que j'attendais. », nous pourrions le lancer nous-mêmes, analyser la sortie et penser que tout est correct, car cela correspond exactement à ce que nous attendions. Nous ne devrions pas avoir à passer du temps pour décoder la sémantique exacte de vos commandes. Tout spécialement, ne vous contentez pas de dire que « Ce n'est pas ce que SQL spécifie/Oracle fait. » Rechercher le comportement correct à partir de SQL n'est pas amusant et nous ne connaissons pas le comportement de tous les autres serveurs de bases de données relationnelles. (Si votre problème est un arrêt brutal du serveur, vous pouvez évidemment omettre cet élément.)
Toutes les options en ligne de commande ainsi que les autres options de lancement incluant les variables d'environnement ou les fichiers de configuration que vous avez modifiées. Encore une fois, soyez exact. Si vous utilisez une distribution prépackagée qui lance le serveur au démarrage, vous devriez essayer de retrouver ce que cette distribution fait.
Tout ce que vous avez fait de différent à partir des instructions d'installation.
La version de PostgreSQL. Vous pouvez lancer
la commande SELECT version(); pour trouver la version
du serveur sur lequel vous êtes connecté. La plupart des exécutables
disposent aussi d'une option --version ;
postgres --version et psql --version
devraient au moins fonctionner. Si la fonction ou les options n'existent
pas, alors votre version est bien trop ancienne et vous devez mettre à
jour. Si vous avez lancé une version préparée sous forme de paquets, tels
que les RPM, dites-le en incluant la sous-version que le paquet pourrait
avoir. Si vous êtes sur une version Git, mentionnez-le en indiquant le
hachage du commit.
Si votre version est antérieure à la 17.2, nous allons certainement vous demander de mettre à jour. Beaucoup de corrections de bogues et d'améliorations sont apportées dans chaque nouvelle version, donc il est bien possible qu'un bogue rencontré dans une ancienne version de PostgreSQL soit déjà corrigé. Nous ne fournissons qu'un support limité pour les sites utilisant d'anciennes versions de PostgreSQL ; si vous avez besoin de plus de support que ce que nous fournissons, considérez l'acquisition d'un contrat de support commercial.
Informations sur la plateforme. Ceci inclut le nom du noyau et sa
version, bibliothèque C, processeur, mémoires et ainsi de suite. Dans la
plupart des cas, il est suffisant de préciser le vendeur et la version,
mais ne supposez pas que tout le monde sait ce que « Debian »
contient ou que tout le monde utilise des x86_64. Si vous avez des problèmes
à l'installation, des informations sur l'ensemble des outils de votre
machine (compilateurs, make, etc.) sont aussi
nécessaires.
N'ayez pas peur si votre rapport de bogue devient assez long. C'est un fait. Il est préférable de rapporter tous les faits la première fois plutôt que nous ayons à vous tirer les vers du nez. D'un autre côté, si vos fichiers d'entrée sont trop gros, il est préférable de demander si quelqu'un souhaite s'y plonger. Voici un article qui donne quelques autres conseils sur les rapports de bogues.
Ne passez pas tout votre temps à vous demander quelles modifications apporter pour que le problème s'en aille. Ceci ne nous aidera probablement pas à le résoudre. S'il arrive que le bogue ne puisse pas être corrigé immédiatement, vous aurez toujours l'opportunité de chercher ceci et de partager vos trouvailles. De même, encore une fois, ne perdez pas votre temps à deviner pourquoi le bogue existe. Nous le trouverons assez rapidement.
Lors de la rédaction d'un rapport de bogue, merci de choisir une terminologie qui ne laisse pas place aux confusions. Le paquet logiciel en totalité est appelé « PostgreSQL », quelquefois « Postgres » en court. Si vous parlez spécifiquement du serveur, mentionnez-le, mais ne dites pas seulement « PostgreSQL a planté ». Un arrêt brutal d'un seul processus serveur est assez différent de l'arrêt brutal du « postgres » père ; merci de ne pas dire que « le serveur a planté » lorsque vous voulez dire qu'un seul processus s'est arrêté, ni vice versa. De plus, les programmes clients tels que l'interface interactive « psql » sont complètement séparés du moteur. Essayez d'être précis sur la provenance du problème : client ou serveur.
En général, envoyez vos rapports de bogue à la liste de discussion des
rapports de bogue (<pgsql-bogues@lists.postgresql.org>). Nous vous
demandons d'utiliser un sujet descriptif pour votre courrier électronique,
par exemple une partie du message d'erreur.
Une autre méthode consiste à remplir le formulaire web disponible sur le
site web du projet. Saisir
un rapport de bogue de cette façon fait que celui-ci est envoyé à la liste
de discussion <pgsql-bogues@lists.postgresql.org>.
Si votre rapport de bogue a des implications sur la sécurité et que vous
préféreriez qu'il ne soit pas immédiatement visible dans les archives
publiques, ne l'envoyez pas sur pgsql-bugs. Les problèmes
de sécurité peuvent être rapportés de façon privée sur
<security@lists.postgresql.org>.
N'envoyez pas de rapports de bogue aux listes de discussion des utilisateurs,
comme <pgsql-sql@lists.postgresql.org> ou
<pgsql-general@lists.postgresql.org>. Ces listes de discussion
servent à répondre aux questions des utilisateurs et les abonnés ne
souhaitent pas recevoir de rapports de bogue. Plus important, ils ont peu
de chance de les corriger.
De même, n'envoyez pas vos rapports de bogue à la liste
de discussion des développeurs <pgsql-hackers@lists.postgresql.org>.
Cette liste sert aux discussions concernant le développement de
PostgreSQL et il serait bon de conserver les
rapports de bogue séparément. Nous pourrions choisir de discuter de votre
rapport de bogue sur pgsql-hackers si le problème
nécessite que plus de personnes s'en occupent.
Si vous avez un problème avec la documentation, le meilleur endroit pour le
rapporter est la liste de discussion pour la documentation
<pgsql-docs@lists.postgresql.org>. Soyez précis sur la partie de la
documentation qui vous déplaît.
Si votre bogue concerne un problème de portabilité sur une plateforme non
supportée, envoyez un courrier électronique à
<pgsql-hackers@lists.postgresql.org>, pour que nous puissions
travailler sur le portage de PostgreSQL sur votre
plateforme.
Dû, malheureusement, au grand nombre de pourriels (spam), toutes les adresses de courrier électronique ci-dessus sont modérées sauf si vous avez souscrit. Ceci signifie qu'il y aura un certain délai avant que l'email ne soit délivré. Si vous souhaitez souscrire aux listes, merci de visiter https://lists.postgresql.org/ pour les instructions.