適正にインストールされ、かつ、すべての機能が使用できるような PostgreSQLインストレーションであっても、浮動小数点の表現とタイムゾーンサポートなどのプラットフォーム特有の誤差のために"失敗"することがあります。現在のテストは単純なdiffを使用して結果の検証を行っているため、システムの些細な違いにも反応します。結果が"失敗"となったら常に実際の結果と予測した結果の差を調査してください。それらの差異が重大ではないことが判明することもあります。なお、全てのテストが成功するするように、サポートする全てのプラットフォームに対する正確な参照ファイルの保守に努めています。
実際のリグレッションテストの出力は src/test/regress/resultsディレクトリ内のファイルに書き込まれます。テストスクリプトはdiffを使用して、各出力ファイルとsrc/test/regress/expectedディレクトリ内の参照用出力とを比較します。あらゆる差異は調査用に src/test/regress/regression.diffsに保存されます(あるいは、自分でdiffを実行することもできます)。
リグレッションテストのいくつかは故意に無効な入力値を使用します。エラーメッセージはPostgreSQLのコードによるもの、または使用しているプラットフォームによるものがあります。後者の場合、プラットフォームによって違いがありますが、似たような内容であるはずです。これらのメッセージの違いによりリグレッションテストは"失敗" する可能性がありますが、これらは検査で確認できます。
リグレッションテストは純粋な"C"ロケールで実行するように実装されています。リグレッションテストドライバはサーバをCロケールで起動させますので、これは一時的なインストレーションに対してテストを実行するときでは特に問題にはならないはずです。しかし、すでにインストールされた、Cロケール以外のサーバに対してテストを実行する際には、文字列のソート順の規則や数、通貨型の整形規則の違いによって違いが生じる可能性があります。
いくつかのロケールでは結果の違いは少なく、検査することによって簡単に確認することができます。しかし、数値の整形規則を変更するロケールでは(特にカンマや小数点を置き換える場合)データ値の入力で失敗する場合があり、したがって、後のテストで存在するはずのデータが存在しないなど大きな差異が生じる場合があります。
timestamp テスト内の問い合わせの中には、夏時間が切り替わる日、または、その前後1日に試験を行った場合に失敗するものがあります。これらの問い合わせは前日の真夜中、当日の真夜中、翌日の真夜中の間の間隔が正確に24時間であることを前提としています。これらは夏時間が始まった時や終った時に異なります。
ほとんどの日付と時刻の結果はタイムゾーンの環境に依存します。参照結果のファイルはPST8PDTタイムゾーン(カリフォルニア州Berkley)を基準に生成されています。したがって、テストがこのタイムゾーンで実行されなければ明らかに失敗に終わります。リグレッションテストのドライバは結果が正しくなるように、PGTZをPST8PDTに設定します。しかし、使用しているシステムはPST8PDTタイムゾーンのライブラリを提供している必要があります。提供されていなければタイムゾーンに依存しているテストは失敗に終わります。使用しているマシンがこの機能をサポートしているかの確認は以下の方法で行うことができます。
$ env TZ=PST8PDT date
上記のコマンドを実行したら、PST8PDTタイムゾーンでの現在のシステム時間を返すはずです。もしPST8PDTのデータベースが存在しなければ、GMT時間で返している可能性があります。 PST8PDTタイムゾーンが存在しなければ、明示的にタイムゾーンのルールを設定することができます。
PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
ローカルなタイムゾーンのルールの明示的な設定に推奨された構文を受け付けないシステムがあります。それらのマシンでは違った PGTZ設定を使用する必要があります。
古いタイムゾーンのライブラリを使っているシステムでは1970年以前の夏時間変更に失敗し、PDT時刻がPST で表現されてしまうという問題があります。これは、テスト結果でローカル時間の違いを生じてしまいます。
64ビット(double precision型)の数値をテーブルの列から取り出して計算を行うテストがあります。double precision列における演算関数では、異なった結果が発生する場合があることが知られています。float8と幾何型テストは特に、プラットフォーム間、またはコンパイラの最適化オプションによる小さな違いが起こりやすくなります。これらのどこが異なっているのかは、人間の目で実際に確かめる必要があります。通常は、小数点以下10桁目ということになるでしょう。
システムによっては、現在のPostgreSQLが想定するメカニズムと異なるために、pow()と exp()でエラーを発生する場合があります。
地形データテストの実行にはカリフォルニアOakland/Berkleyの道路地図を参照しています。この地図は多角形として表現されていて、その頂点は double precision型の数の(十進数での緯度と経度の)対で表されます。まず最初にいくつかの地形データが格納されたテーブルが生成され、多角形の交点演算子(##)を使って2つのテーブルを結合するビューが生成され、そのビュー上でselectが行われます。
異なるプラットフォームの結果を比較する場合は、小数点第2位、もしくは第3位で違いが生じます。これらの違いが起こるSQL文は下記のようなものです。
SELECT * from street; SELECT * from iexit;
同じ行の出力が期待されるファイルで記述されている順序とは異なっている場合があります。ほとんどの場合、これは厳密にいってバグではありません。ほとんどのリグレッションテストは各SELECT文に対してORDER BYを使用するほど規則に厳しくなく、また、結果の行の順序はSQLの仕様でははっきりとは定義されていません。実際には、同じソフトウェアで、同じデータを同じ問い合わせで参照しているのですべてのプラットフォームで同じ順序の結果が返され、よって、ORDER BYの問題ではないといえます。しかし、問い合わせによっては、プラットフォーム間の順序の違いが起こる可能性があります(順序の違いはC以外のロケール設定でも起こり得ます)。
したがって、順序の違いが起こった場合、問い合わせにORDER BYが含まれていて順序が影響を及ぼす場合以外は、気にしないでください。しかし、将来のリリースで、特定の問い合わせにORDER BYを追加して、偽の"失敗" を取り除くために一報ください。
このような問題を回避させるために、リグレッションテストの問い合わせに順序関連のコマンドを挿入しない理由として、それを行うと、必要がない問い合わせに対しても問い合わせ計画型を実行しようとするなどのことからリグレッションテストの意義を逆に半減させることが挙げられます。
"乱数"テストには、無作為な結果を出力することが想定されているテストケースが、少なくとも1つあります。この乱数により、時として(おそらく5回から10回のうちに1回は)リグレッションテストが失敗に終わることがあります。
diff results/random.out expected/random.out
上記のコマンドを入力すると、数行程度の差異のみがあるはずです。毎回失敗するのでなければ、気に留める必要はありません。(逆に、リグレッションテストを行い、毎回成功する場合は気に留める必要があるかもしれません。)