★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

5. バグレポートガイドライン

PostgreSQLに関してバグを発見した場合、ぜひ連絡してください。最大限の注意を払ってもすべてのプラットフォーム、すべての環境で PostgreSQLの機能すべてが正常に動くことを保証できないので、バグレポートはPostgreSQLをより信頼性の高いものにするために、大変重要になります。

下記の助言は、バグレポートが有効的に活用されるためのものです。これに従う義務はありませんが、沿った方がより有益なものとなるでしょう。

発見されたバグはただちに修正されるとは限りません。そのバグが明確で、重大で、他の多くのユーザーにも影響を与えるものであれば、すぐに修正される可能性が高いでしょう。また、より新しいバージョンに変えて、そこでも同じようなことが起こるかを確認してもらうようにお勧めする場合もあります。あるいは、現在計画中の大きな変更が終了するまでバグが修正しないと判断する場合もあります。また、そのバグ修正はとても難易度が高いもので、後まわしになることも考えられます。早急に処置が必要な場合は、商用サポートの購入を検討してください。

5.1. バグの特定

バグ報告を行う前に、ドキュメントを読み、もう一度読み返し、実行しようとしている処理が実行可能かどうか確認してください。実行可能かどうかが不明な場合は、その旨を報告してください(それはある意味ドキュメントのバグです)。また、ドキュメントに書かれていることと実際の結果が異なる場合はそれはバグとなります。以下のような状況が考えられます。しかしこれらに限定しているわけではありません。

ここでは、"プログラム"とはバックエンドサーバだけではなく、何らかの実行可能ファイルを意味します。

プログラムの実行が遅かったり、リソースを大量に使用するのは必ずしもバグではありません。アプリケーションを改善するためには、ドキュメントを読んだり、メーリングリストで尋ねてみたりしてください。SQL標準の要求に応じない場合、その機能の互換性を明確にうたっていない限り、それはバグとはいえません。

また、TODOリストや、FAQで、そのバグが既知のものかどうか確認してください。もしTODOリストから情報を読みとることができなければ、問題を報告してください。少なくとも TODO リストを判りやすくすることができます。

5.2. 報告すべきこと

バグ報告でもっとも重要なことは、すべての事実を明確に記述し、また、記述されたものは事実のみである、ということです。何が起こったのか、または、プログラムのどこが問題か、"何々が起こっているようだ"などの憶測や推測を記述しないでください。実装にさほど詳しくない方の推測は正しくない場合があり、有効なバグ報告になりません。実装に精通している方の場合でも、根拠のある説明は参考情報となりますが、やはり正しい事実が一番役に立ちます。バグを修正するためには、まず開発者自身がそのバグを再現する必要があります。ありのままの事実を報告するのは単刀直入(多くの場合画面からメッセージをコピー&ペーストを行うのみ)ですが、得てして、重要でないだろうと想像したり、省いても理解してもらえるだろうと思いこむことにより重要な情報が洩れてしまう場合がかなり多くあります。

すべてのバグ報告では、下記の内容が記述されていなければいけません。

バグ報告が長文になってもそれは仕方がないことなので、気にしないでください。一度にすべての情報を入手できる方が、開発者から情報を催促するよりも手間暇がかかりません。その一方、ファイルが大きいならば、その情報に誰か興味があるかを始めに尋ねるのが得策かもしれません。

問題を解決させる入力を見つけ出すための試行錯誤に時間をかけないで下さい。これはおそらく問題解決の助けになりません。バグが即座に修正されない場合、その間を利用してさまざまと試してみてください。繰返しになりますが、バグがなぜあるのかを解明するのに余計な時間を取る必要はありません。開発者の方が十分速くそれを見つけ出します。

バグ報告をする際、理解しやすい用語を使用してください。このソフトウェアパッケージ全体は"PostgreSQL" と呼ばれていますが、略して "Postgres"とも呼ばれます。特にバックエンドサーバに関して述べるときは、そのように明記し、"PostgreSQLのクラッシュ"とは記述しないでください。1つのバックエンドサーバのクラッシュとその親プロセス "postmaster" とはかなり異なります。1つのバックエンドがダウンしてしまったことを"postmaster のクラッシュ" とは記述しないで下さい。また、"psql"対話式フロントエンドなどのクライアントプログラムはバックエンドとは完全に分離されています。問題がクライアント側かサーバ側かの切り分けを試みて下さい。

5.3. バグ報告先

一般的には、というバグ報告用メーリングリストにバグ報告を送ってください。バグ報告の題名には、エラーメッセージの一部分などを使ってください。

他に、プロジェクトの web サイト http://www.postgresql.org/ にあるバグ報告フォームの項目を埋める方法があります。この方法で入力したバグ報告は、 メーリングリストに送信されます。

などのユーザ向けのメーリングリストには決してバグ報告を送らないでください。これらのメーリングリストはバグ報告を必要としないユーザの場となっています。また、多くの場合、そのメーリングリストに参加している人はバグを修正してくれる可能性は低いでしょう。

また、にもバグ報告を 送らないでください。ここは PostgreSQLの開発に関して議論する場で、バグ報告とは切り離している方がよいとされています。もしその問題により多くのレビューが必要な場合は、そのバグ報告を pgsql-hackers で議論するすることになります。

ドキュメントに関して問題がある場合は、ドキュメント用のメーリングリスト、 が最適な報告先です。その際、問題になった箇所がどの部分かを明記して下さい。

また、サポートされていないプラットフォームへの移植に関係するバグ報告である場合はに報告してください。そのプラットフォームへPostgreSQLを移植するように最善の努力をします。

Note: spamメールを防止するために、残念なことに、これらのメーリングリストはclosedとなっています。つまり、これらのメーリングリストに投稿するには、講読しなければいけません(しかし、webフォームによるバグ報告の場合は購読する必要はありません)。単にメールを送りたい場合は、購読し、講読オプションを nomailに設定してください。より詳細については 宛に、helpとだけ本文に書いてメールを送ってください。