Regression 結果の解析

The results are in files in the ./results directory. These results can be compared with results in the ./expected directory using 'diff'. (The test script does this for you, and leaves the differences in ./regression.diffs.)

テストの結果は ./results ディレクトリにファイルとして出力されます。 それらの結果は 'diff' を使って ./expected ディレクトリ の結果と比較することが可能です。 (テストスクリプトはこのことを実行しないで、差異 ./regression.diffs に出力するだけです。)

The files might not compare exactly. The test script will report any difference as a "failure", but the difference might be due to small cross-system differences in error message wording, math library behavior, etc. "Failures" of this type do not indicate a problem with Postgres.

ファイルは厳密に比較されるとは限りません。テストスクリプトは どんな差異も"失敗"と報告しますが、それらの差異はちょっとした プラットフォームの違いから来るエラーメッセージの表現のしかた や演算ライブラリなどによる場合もあります。 この種の"失敗"はPostgres に問題が ある事を示しているわけではありません。

Thus, it is necessary to examine the actual differences for each "failed" test to determine whether there is really a problem. The following paragraphs attempt to provide some guidance in determining whether a difference is significant or not.

従って、それぞれの"失敗"したテストについて実際の違いを検証して 本当に問題なのかどうかを判別する必要があります。 下記の項では、差異が重要か否かを判別する上での指針を記述します。


Some of the regression tests involve intentional invalid input values. Error messages can come from either the Postgres code or from the host platform system routines. In the latter case, the messages may vary between platforms, but should reflect similar information. These differences in messages will result in a "failed" regression test which can be validated by inspection.

regression テストの中には、故意に無効な入力値を与えるものがあります。 このため Postgres のコード、およびホストのプラットフォームのシステム ルーチンの両方からエラーメッセージを受ける場合があります。後者の場合 メッセージはプラットフォームにより異なるでしょうが、似たような 情報のはずです。これらのメッセージの違いにより regression テストは "失敗"するでしょうが、これは検査で確認できます。

OID の違い

There are several places where PostgreSQL OID (object identifiers) appear in 'regress.out'. OID's are unique 32-bit integers which are generated by the PostgreSQL backend whenever a table row is inserted or updated. If you run the regression test on a non-virgin database or run it multiple times, the OID's reported will have different values. The following SQL statements in 'misc.out' have shown this behavior: QUERY: SELECT user_relns() AS user_relns ORDER BY user_relns; The 'a,523676' row is composed from an OID.

'regress.out' において、PostgreSQL の OID (オブジェクト識別子)が現れる ところがいくつかあります。OID はユニークな 32 ビットの整数で、 テーブルに行を INSERT したり UPDATE したりするたびに、PostgreSQL の バックエンドにより生成されます。まっさらでないデータベースで regression テストを実行したり、何度も実行したりすると、OID は異なった 値で報告されます。 'misc.out' にある以下の SQL 文 QUERY: SELECT user_relns() AS user_relns ORDER BY user_relns; では、OID から 'a,523676' という行が作られます。


Most of the date and time results are dependent on timezone environment. The reference files are generated for timezone PST8PDT (Berkeley, California) and there will be apparent failures if the tests are not run with that timezone setting. The regression test driver sets environment variable PGTZ to PST8PDT to ensure proper results.

ほとんどの日付と時刻の結果は時間帯の環境に依存します。 差異結果のファイルは PST8PDT 時間帯(カリフォルニア・バークレイ) を基準に生成されます。ですからテストがこの時間帯で実行されなければ 明らかに失敗に終ります。regression テストのドライバは結果が 正しくなるように、環境変数 PGTZ を PST8PDT に設定します。

There appear to be some systems which do not accept the recommended syntax for explicitly setting the local time zone rules; you may need to use a different PGTZ setting on such machines.

ローカルな時間帯を明示的に設定する際に推奨される書式を受け付けない システムがいくつか見受けられます。それらのシステムでは別の PGTZ 設定の仕方を行って下さい。

Some systems using older timezone libraries fail to apply daylight-savings corrections to pre-1970 dates, causing pre-1970 PDT times to be displayed in PST instead. This will result in localized differences in the test results.

旧い時間帯のライブラリを使っているシステムでは 1970 年以前の夏時間変更に 失敗し、PDT 時刻 が PST で表現されてしまうという問題があります。 このためテスト結果でローカル時間の違いとなってしまいます。


Some of the tests involve computing 64-bit (float8) numbers from table columns. Differences in results involving mathematical functions of float8 columns have been observed. The float8 and geometry tests are particularly prone to small differences across platforms. Human eyeball comparison is needed to determine the real significance of these differences which are usually 10 places to the right of the decimal point.

いくつかのテストでは、64 ビット (float8) 数値をテーブルの カラムから取り出して計算を行います。float8 カラムにおける 演算関数では、異なった結果が発生する場合があることが知られています。 float8 と地形テストは特にプラットホーム間の小さな違いで問題を おこりやすくしています。 これらのどこが異なっているのかは、人間の目で確かめる必要があります。 通常は、小数点以下 10 桁目ということになるでしょう。

Some systems signal errors from pow() and exp() differently from the mechanism expected by the current Postgres code.

システムによっては、pow() と exp() の振る舞いが現在の Postgres の コードが期待するものと異なるため、シグナル・エラーが発生するものも あります。


Several of the tests involve operations on geographic date about the Oakland/Berkley CA street map. The map data is expressed as polygons whose vertices are represented as pairs of float8 numbers (decimal latitude and longitude). Initially, some tables are created and loaded with geographic data, then some views are created which join two tables using the polygon intersection operator (##), then a select is done on the view. When comparing the results from different platforms, differences occur in the 2nd or 3rd place to the right of the decimal point. The SQL statements where these problems occur are the folowing:

	  QUERY: SELECT * from street;
	  QUERY: SELECT * from iexit;

地形データテストの実行には カリフォルニア Oakland/Berkley の道路地図を 参照しています。地図データは多角形として表現されており、頂点は float8 数の(十進数での緯度と経度の)対で表されます。 まず最初にいくつかのテーブルが生成され、地形データが読み込れます。 その後、多角形の交点演算子(##)を使って 2 つのテーブルを join する view が生成され、その view 上で select が行われます。 異なったプラットフォームからの結果を比較すると、小数点以下 2 桁目と 3 桁目で違いが発生します。これらの問題が起こる場合の SQL 文は以下の 通りです。

            QUERY: SELECT * from street;
            QUERY: SELECT * from iexit;


There is at least one test case in random.out which is intended to produce random results. This causes random to fail the regression testing once in a while. Typing

	  diff results/random.out expected/random.out
should produce only one or a few lines of differences for this reason, but other floating point differences on dissimilar architectures might cause many more differences. See the release notes below.

random.out に無作為の結果を出力することが想定されているテストケースが、 すくなくとも 1 つあります。この乱数により、ときたま regression は失敗 します。

          diff results/random.out expected/random.out
と入力してみると、この理由による違いは若干しか見当たらないことが あります。しかし、異なったアーキテクチャ上における浮動小数点数の 違いは、こんなものではないでしょう。 後述のリリースノートを参照してください。

"expected" ファイル

The ./expected/*.out files were adapted from the original monolithic expected.input file provided by Jolly Chen et al. Newer versions of these files generated on various development machines have been substituted after careful (?) inspection. Many of the development machines are running a Unix OS variant (FreeBSD, Linux, etc) on Ix86 hardware. The original expected.input file was created on a SPARC Solaris 2.4 system using the postgres5-1.02a5.tar.gz source tree. It was compared with a file created on an I386 Solaris 2.4 system and the differences were only in the floating point polygons in the 3rd digit to the right of the decimal point. (see below) The original sample.regress.out file was from the postgres-1.01 release constructed by Jolly Chen and is included here for reference. It may have been created on a DEC ALPHA machine as the in the postgres-1.01 release has PORTNAME=alpha.

./expected/*.out ファイルは Jolly Chen らによって 提供された単体のオリジナルファイル expected.input を基にしています。 より新しいバージョンは、注意深く?検査された後に、オリジナルに取って 代わりました。Ix86 ハードウェア上で多くの開発マシンが、いろいろな UNIX OS の派生系(FreeBSD、Linux など)で動いています。 オリジナルの expected.input は、 postgres5-1.02a5.tar.gz ソースツリーを使って、 SPARC Solaris 2.4 システム上で作られました。このファイルは、ある I386 Solaris 2.4 システムで作られたファイルと比較されましたが、違いは、 浮動小数点多角形の小数点以下 3 桁目の数字のみでした(後述)。 オリジナルの sample.regress.out ファイルは、 Jolly Chen により構築された postgres-1.01 リリースで作られたもの ですが、参照としてここに引用されています。postgres-1.01 リリースの は PORTNAME=alpha となって いますので DEC ALPHA マシン上で生成されたものかもしれません。