適正にインストールされ、かつ、すべての機能が使用できるようなPostgreSQLインストレーションであっても、浮動小数点の表現とタイムゾーンサポートなどのプラットフォーム特有の誤差のために"失敗"することがあります。 現在のテストは単純に、参照用システムで生成した出力とのdiffを取ることで結果の検証を行っているため、システムの些細な違いにも反応します。 結果が"失敗"となったら常に実際の結果と予測した結果の差を調査してください。 それらの差異が重大ではないことが判明することもあります。 なお、全てのテストが成功するするように、サポートする全てのプラットフォームに対する正確な参照ファイルの保守に努めています。
実際のリグレッションテストの出力はsrc/test/regress/resultsディレクトリ内のファイルに書き込まれます。 テストスクリプトはdiffを使用して、各出力ファイルとsrc/test/regress/expectedディレクトリ内の参照用出力とを比較します。 あらゆる差異は調査用にsrc/test/regress/regression.diffsに保存されます （あるいは、自分でdiffを実行することもできます）。
リグレッションテストのいくつかは故意に無効な入力値を使用します。 エラーメッセージはPostgreSQLのコードによるもの、または使用しているプラットフォームの関数によるものがあります。 後者の場合、プラットフォームによって違いがありますが、似たような内容であるはずです。 これらのメッセージの違いによりリグレッションテストは"失敗"する可能性がありますが、これらは検査で確認できます。
すでにインストールされている、C ロケール以外の照合順ロケールで初期化されたサーバに対してテストを実行する際には、ソート順やフォローアップの失敗によって違いが生じる可能性があります。 リグレッションテストスイートはこの問題を解決するために、多くのロケールを処理するための代替の結果ファイルを提供するように設定されています。 例えば、char テストの場合、予定されている char.out というファイルが C ロケールと POSIX ロケールを処理し、char_1.out というファイルが他の多くのロケールを処理します。 リグレッションテストドライバは、成功したかどうか検査したり、失敗の違いを計算したりする際に、照合に一番適したファイルを自動的に選出します。 (これは、リグレッションテストが、構成されたロケールにとって結果か適切などうかを検出できないことを意味します。 このテストは単に作業に最も適切な結果ファイルを 1つ選出するものです。)
既存の予定されているファイルがなんらかの理由で一部のロケールをカバーできない場合は、新規ファイルを追加することができます。 このファイルの名前の形式は testname_digit.out です。 実際の数値 (digit) はそれほど重要ではありません。 リグレッションテストドライバはこのようなファイルすべてを同様に有効なテスト結果とみなすことを忘れないで下さい。 テスト結果がプラットフォームに固有のものである場合は、代わりに 項26.3 で説明した方法を使用してください。
horology テスト内の問い合わせの中には、夏時間が切り替わる日、または、その前後 1 日に試験を行った場合に失敗するものがあります。 これらの問い合わせは前日の真夜中、当日の真夜中、翌日の真夜中の間の間隔が正確に24時間であることを前提としています。 これらは夏時間が始まった時や終った時に異なります。
注意: 米国夏時間規則を使用しているため、この問題は、4月第一日曜、10月最終土曜日、および両者のその次の月曜日に必ず発生します。 実際の使用環境で夏時間の影響がいつ現れるかには関係しません。 また、パシフィック時間(UTC-7もしくはUTC-8)深夜にこの問題が発生、もしくは、解消することにも注意してください。これも使用環境での深夜ではありません。 従って、この失敗は使用環境に依存して、土曜の遅くに発生し、火曜日まで続く可能性があります。
ほとんどの日付と時刻の結果はタイムゾーンの環境に依存します。 参照結果のファイルはPST8PDTタイムゾーン（カリフォルニア州Berkeley）を基準に生成されています。 したがって、テストがこのタイムゾーンで実行されなければ明らかに失敗に終わります。 リグレッションテストのドライバは結果が正しくなるように、PGTZ環境変数をPST8PDTに設定します。 しかし、使用しているオペレーティングシステムはPST8PDTタイムゾーンをサポートしている必要があります。 提供されていなければタイムゾーンに依存しているテストは失敗に終わります。 使用しているマシンがこの機能をサポートしているかの確認は以下の方法で行うことができます。
env TZ=PST8PDT date
上記のコマンドを実行したら、PST8PDTタイムゾーンでの現在のシステム時間を返すはずです。 もしPST8PDTタイムゾーンが利用できなければ、UTC時間で返している可能性があります。 PST8PDTタイムゾーンが存在しなければ、以下のように明示的にタイムゾーンの規則を設定することができます。
PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
ローカルなタイムゾーンの規則の明示的な設定に推奨された構文を受け付けないシステムがあります。 それらのマシンでは違ったPGTZ設定を使用する必要があります。
古いタイムゾーンのライブラリを使っているシステムでは1970年以前の夏時間の修正に失敗し、1970年以前のPDT時刻がPSTで表現されてしまうという問題があります。 このため、テスト結果でローカル時間の違いを生じてしまいます。
64ビット（double precision型）の浮動小数点数値をテーブルの列から取り出して計算を行うテストがあります。 double precision列における数学演算関数では、異なった結果が発生する場合があることが知られています。 float8とgeometryテストは特に、プラットフォーム間、またはコンパイラの最適化オプションによる小さな違いが起こりやすくなります。 これらの違いが重要なのか無視できるのかは、人間の目で実際に確かめる必要があります。 通常は、小数点以下10桁目ということになるでしょう。
システムによって、マイナス0を-0と表示するものも、単に0と表示するものもあります。
システムによっては、現在のPostgreSQLのコードが想定するメカニズムと異なるために、pow()とexp()でエラーを発生する場合があります。
同じ行の出力が期待されるファイルで記述されている順序とは異なっている場合があります。 ほとんどの場合、これは厳密にいってバグではありません。 ほとんどのリグレッションテストは各SELECT文に対してORDER BYを使用するほど規則に厳しくなく、そのため、結果の行の順序はSQLの仕様に従って、明確に決まっていません。 実際には、同じソフトウェアで、同じデータを同じ問い合わせで参照しているのですべてのプラットフォームで同じ順序の結果が返され、よって、ORDER BYがないことは問題ではないといえます。 しかし、問い合わせによっては、プラットフォーム間の順序の違いが起こる可能性があります （順序の違いはC以外のロケール設定でも起こり得ます）。
したがって、順序の違いが起こった場合、問い合わせにORDER BYが含まれていて順序が影響を及ぼす場合以外は、気にしないでください。 しかし、将来のリリースで、特定の問い合わせにORDER BYを追加して、偽の"失敗"を取り除くために一報ください。
このような問題を回避させるために、リグレッションテストの問い合わせに順序関連のコマンドを挿入しない理由として、それを行うと、必要がない問い合わせに対しても問い合わせ計画型を実行しようとするなどのことからリグレッションテストの意義を逆に半減させることが挙げられます。