他のバージョンの文書 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

32.2. テストの評価

適正にインストールされ、かつ、すべての機能が使用できるようなPostgreSQLインストレーションであっても、浮動小数点の表現やメッセージ内の単語順など、プラットフォーム特有の誤差のために失敗することがあります。 現在のテストは単純に、(基準となる)参照用システムで生成した出力とのdiffを取ることで結果の検証を行っているため、システムの些細な違いにも反応します。 結果が失敗となった場合は、予測された結果と実際の結果との差分を必ず評価してください。 それらの差異が重大ではないことが判明することもあります。 なお、すべてのテストが成功するように、サポートするすべてのプラットフォームに対する正確な参照ファイルの保守に努めています。

実際のリグレッションテストの出力は、src/test/regress/resultsディレクトリ内のファイルに書き込まれます。 テストスクリプトはdiffを使用して、各出力ファイルとsrc/test/regress/expectedディレクトリ内の参照用出力とを比較します。 あらゆる差異は調査用にsrc/test/regress/regression.diffsに保存されます。 (コアテスト以外のテストスイートを実行する場合には、上記のファイルはもちろんsrc/test/regressではなく適切なサブディレクトリに現れます。)

デフォルトで利用されているdiffオプションが気に入らなければ、例えばPG_REGRESS_DIFF_OPTS='-u'のように、環境変数PG_REGRESS_DIFF_OPTSを設定して下さい。 (あるいは、自分でdiffを実行することもできます。)

何らかの理由で、特定のプラットフォームが指定した試験で失敗し、その出力の調査により結果の方が有効であると確信できた場合、新しい比較用ファイルを追加し、今後の試験で失敗の報告が発生しないようにすることができます。 詳細は32.3を参照してください。

32.2.1. エラーメッセージの違い

リグレッションテストのいくつかは、意図的に無効な入力値を使用します。 エラーメッセージはPostgreSQLのコードによるもの、または使用しているプラットフォームの関数によるものがあります。 後者の場合、プラットフォームによって違いがあるかもしれませんが、似たような内容になるはずです。 これらのメッセージの違いによりリグレッションテストは失敗する可能性がありますが、これらは検査で確認できます。

32.2.2. ロケールの違い

Cロケール以外の照合順序のロケールで初期化されたサーバに対してテストを実行する際には、ソート順やその後に発生する失敗に違いが生じる可能性があります。 リグレッションテストスイートはこの問題を解決するために、多くのロケールを処理するための代替の結果ファイルを提供するように設定されています。

一時的なインストレーションを使用して、異なるロケールのテストを実行するためには、以下の例のように、makeコマンドラインに適切なロケール関連の環境変数を渡してください。

make check LANG=de_DE.utf8

(リグレッションテストのドライバはLC_ALLを設定しないため、この変数を使ってロケールを選択することはできません。) ロケール無しを使用するためには、すべてのロケール関連の環境変数を設定しない(または、それらをCに設定する)か、もしくは以下の特殊な起動を行います。

make check NO_LOCALE=1

既存のインストレーションに対してテストを実行する場合は、ロケール設定は既存のインストレーションによって決まります。 変更するためには、initdbに適切なオプションを渡して、異なるロケールでデータベースクラスタを初期化してください。

実際に実運用で使用されるロケールおよび符号化方式に関連した部分のコードが検証されますので、一般的には、実運用で使用されるロケール設定でリグレッションテストを実行することを推奨します。 オペレーティングシステム環境に依存して、結果が失敗する場合もありますが、少なくとも実際のアプリケーションを実行する時に想定されるロケール固有の動作を知ることができます。

32.2.3. 日付と時刻の違い

日付と時刻の結果のほとんどはタイムゾーンの環境に依存します。 参照ファイルはタイムゾーン PST8PDT (Berkeley, California) 用に生成されているため、このタイムゾーン設定で実行されていないテストは明らかに失敗します。 リグレッションテストのドライバは、適切な結果を保証するために、環境変数PGTZPST8PDTを設定します。

32.2.4. 浮動小数点数の違い

いくつかのテストでは、64ビット(double precision型)の浮動小数点数値をテーブルの列から取り出して計算を行います。 double precision列における数学演算関数では、異なった結果が発生する場合があることが知られています。 float8geometryテストは特に、プラットフォーム間、またはコンパイラの最適化の設定による小さな違いが起こりやすくなります。 これらの違い、通常は小数点以下10桁目以降の相違の、実際の影響度を判断するためには、人間の目で実際に確認する必要があります。

いくつかのシステムではマイナス0を-0と表示することがあり、その他のシステムでは単に0と表示します。

いくつかのシステムでは、現在のPostgreSQLのコードが想定しているメカニズムと異なるために、pow()exp()でエラーを発生する場合があります。

32.2.5. 行の順序の違い

同じ行の出力が、参照ファイルで記述されている順序とは異なっている場合があります。 ほとんどの場合、これは厳密に言ってバグではありません。 ほとんどのリグレッションテストは、各SELECT文に対してORDER BYを使用するほど規則に厳しくなく、そのため、結果の行の順序はSQLの仕様に従って、明確に決まっていません。 実際には、同じソフトウェアで同じデータを用いて同じ問い合わせで参照しているので、すべてのプラットフォームで同じ順序の結果が返されるため、ORDER BYがないことは問題ではないと言えます。 しかし、問い合わせによっては、プラットフォーム間の順序の違いが起こる可能性があります。 インストール済みのサーバに対して試験を行う場合、C以外のロケール、独自のwork_memや独自のプランナ用のコストパラメータなどデフォルト以外のパラメータ設定により順序の違いが生じる可能性があります。

したがって、順序の違いを見つけた場合、問い合わせにORDER BYが含まれていて順序が影響を及ぼす場合以外は、気にする必要はありません。 ただし、その場合にもとにかくご一報ください。特定の問い合わせから偽の失敗を取り除くために、将来のリリースにおいて、ORDER BYを追加します。

このような問題を避けるために、なぜ我々がすべてのリグレッションテストに対して明示的に順序を指定しないのか、疑問に思うかもしれません。 その理由は、ソートが必要がない場合であってもソートされた結果を生成する問い合わせ計画を実行しようとすることによって、リグレッションテストの意義が増すわけではなく、むしろ減るからです。

32.2.6. スタック長の不足

errorsテストがselect infinite_recurse()コマンドでサーバをクラッシュさせた場合、プラットフォームのプロセススタックサイズがmax_stack_depthパラメータが示す値よりも小さいことを意味します。 これは、スタックサイズ制限を高くして(デフォルトのmax_stack_depthでの推奨値は4メガバイト)サーバを実行することで修正することができます。 これを行うことができない場合、max_stack_depthの値を少なくすることが代替方法です。

getrlimit()をサポートするプラットフォームでは、サーバは自動的にmax_stack_depthの安全な値を選ぶべきです。 この設定を手で上書きしたのでない限り、この種の失敗は報告する価値のあるバグです。

32.2.7. 乱数 テスト

randomテストスクリプトは、無作為な結果を生成することを目的としています。 非常に稀ですが、これがリグレッションテストが失敗する原因になることがあります。 次のように、

diff results/random.out expected/random.out

と入力すると、ほんの数行だけの差異が生じるはずです。 繰り返し失敗しない限り、気に留める必要はありません。

32.2.8. 設定パラメータ

既存のインストレーションに対してテストを実行する場合、デフォルトでないパラメータ設定はテストが失敗する原因になり得ます。 例えば、enable_seqscanenable_indexscanのようなパラメータの変更は、EXPLAINを使うテストの結果に影響する計画の変更の原因となり得ます。