Postgresql 中文操作指南
33.2. Test Evaluation #
一些正确安装且完全正常运行的 PostgreSQL 安装可能会由于平台特定机制（例如浮点数表示以及消息表述不同）“未通过”其中一些回归测试。目前使用一个简单的 diff 比较针对一个参考系统上生成的结果来评估测试，因此结果对系统差异很敏感。如果报告测试“未通过”，务必检查预期结果和实际结果之间的差异；你会发现差异可能并不重要。尽管如此，我们仍努力维护所有支持平台上的准确参考文件，因此可以预期所有测试都会通过。
Some properly installed and fully functional PostgreSQL installations can “fail” some of these regression tests due to platform-specific artifacts such as varying floating-point representation and message wording. The tests are currently evaluated using a simple diff comparison against the outputs generated on a reference system, so the results are sensitive to small system differences. When a test is reported as “failed”, always examine the differences between expected and actual results; you might find that the differences are not significant. Nonetheless, we still strive to maintain accurate reference files across all supported platforms, so it can be expected that all tests pass.
回归测试的实际结果位于 src/test/regress/results 目录下的文件中。测试脚本使用 diff 将每个输出文件与 src/test/regress/expected 目录下存储的参考输出进行比较。任何差异都会保存在 src/test/regress/regression.diffs 中供你检查。（在运行除核心测试之外的测试套件时，这些文件当然会出现在相关子目录中，而不会出现在 src/test/regress 中。）
The actual outputs of the regression tests are in files in the src/test/regress/results directory. The test script uses diff to compare each output file against the reference outputs stored in the src/test/regress/expected directory. Any differences are saved for your inspection in src/test/regress/regression.diffs. (When running a test suite other than the core tests, these files of course appear in the relevant subdirectory, not src/test/regress.)
如果你不喜欢默认使用的 diff 选项，请设置环境变量 PG_REGRESS_DIFF_OPTS，例如 PG_REGRESS_DIFF_OPTS='-c'。（如果你愿意，也可以自己运行 diff。）
If you don’t like the diff options that are used by default, set the environment variable PG_REGRESS_DIFF_OPTS, for instance PG_REGRESS_DIFF_OPTS='-c'. (Or you can run diff yourself, if you prefer.)
如果出于某种原因，特定平台为特定测试生成了“失败”，但检查输出使您确信结果有效，则可以添加一个新的比较文件以在将来的测试运行中消除故障报告。有关详细信息，请参阅 Section 33.3。
If for some reason a particular platform generates a “failure” for a given test, but inspection of the output convinces you that the result is valid, you can add a new comparison file to silence the failure report in future test runs. See Section 33.3 for details.
33.2.1. Error Message Differences #
一些回归测试包含有意提供的无效输入值。错误消息可以来自 PostgreSQL 代码或者来自主机平台系统例程。在后一种情况下，消息可能因平台而异，但应反映相似信息。这些消息差异将导致可以经由检查验证的回归测试“失败”。
Some of the regression tests involve intentional invalid input values. Error messages can come from either the PostgreSQL code or from the host platform system routines. In the latter case, the messages can vary between platforms, but should reflect similar information. These differences in messages will result in a “failed” regression test that can be validated by inspection.
33.2.2. Locale Differences #
如果针对在用以 C 以外的排序顺序区域设置初始化的服务器运行测试，则可能由于排序顺序和后续失败而产生差异。回归测试套件通过提供备用结果文件来解决此问题，而这些文件共同处理大量区域设置。
If you run the tests against a server that was initialized with a collation-order locale other than C, then there might be differences due to sort order and subsequent failures. The regression test suite is set up to handle this problem by providing alternate result files that together are known to handle a large number of locales.
要在使用临时安装方法时在不同区域设置中运行测试，请在 make 命令行上传递相应的区域设置相关环境变量，例如：
To run the tests in a different locale when using the temporary-installation method, pass the appropriate locale-related environment variables on the make command line, for example:
make check LANG=de_DE.utf8（回归测试驱动程序会取消设置 LC_ALL，因此无法使用该变量选择区域设置。）要不用区域设置，请取消设置所有区域设置相关环境变量（或将其设置为 C），或使用以下特殊调用：
(The regression test driver unsets LC_ALL, so it does not work to choose the locale using that variable.) To use no locale, either unset all locale-related environment variables (or set them to C) or use the following special invocation:
make check NO_LOCALE=1在针对现有安装运行测试时，区域设置取决于现有安装。要更改该设置，请将适当的选项传递给 initdb，以在不同区域设置下初始化数据库集群。
When running the tests against an existing installation, the locale setup is determined by the existing installation. To change it, initialize the database cluster with a different locale by passing the appropriate options to initdb.
总而言之，建议尝试在希望用于生产的区域设置下运行回归测试，因为这将激活生产中实际将要使用的区域设置和编码相关的代码部分。根据操作系统环境，你可能会遇到一些失败，但这样你至少会知道在运行真实应用程序时会产生哪些区域设置特定的行为。
In general, it is advisable to try to run the regression tests in the locale setup that is wanted for production use, as this will exercise the locale- and encoding-related code portions that will actually be used in production. Depending on the operating system environment, you might get failures, but then you will at least know what locale-specific behaviors to expect when running real applications.
33.2.3. Date and Time Differences #
大部分日期和时间结果都依赖于时区环境。参考文件为时区 PST8PDT（加利福尼亚州伯克利市）生成，如果不使用该时区设置运行测试，则会出现明显的失败。回归测试驱动程序会将环境变量 PGTZ 设置为 PST8PDT，这通常可确保获得正确的结果。
Most of the date and time results are dependent on the time zone environment. The reference files are generated for time zone PST8PDT (Berkeley, California), and there will be apparent failures if the tests are not run with that time zone setting. The regression test driver sets environment variable PGTZ to PST8PDT, which normally ensures proper results.
33.2.4. Floating-Point Differences #
一些测试涉及从表列中计算 64 位浮点数（double precision）。已经观察到涉及数学函数的 double precision 列的结果差异。float8 和 geometry 测试特别容易出现跨平台的微小差异，甚至在不同的编译器优化设置下也会出现差异。需要人眼比较才能确定这些差异的实际意义，这些差异通常出现在小数点右侧的第 10 位。
Some of the tests involve computing 64-bit floating-point numbers (double precision) from table columns. Differences in results involving mathematical functions of double precision columns have been observed. The float8 and geometry tests are particularly prone to small differences across platforms, or even with different compiler optimization settings. 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.
一些系统将负零显示为 -0，而另一些系统则仅显示 0。
Some systems display minus zero as -0, while others just show 0.
一些系统传达来自 pow() 和 exp() 的错误的方式与当前 PostgreSQL 代码所期望的机制不同。
Some systems signal errors from pow() and exp() differently from the mechanism expected by the current PostgreSQL code.
33.2.5. Row Ordering Differences #
你可能会看到一些相对于预期文件中出现的差异，而在这些差异中，相同的行以不同的顺序输出。在大多数情况下，严格来说，这并不是一个错误。大多数回归测试脚本不会那么学究气，以至于会对每一个 SELECT 都使用 ORDER BY，因此它们的按结果排序并不是按照 SQL 规范明确定义的。实际上，由于我们查看的是相同软件在相同数据上执行的相同查询，我们通常在所有平台上获得相同的排序结果，因此缺乏 ORDER BY 并不是问题。然而，某些查询确实表现出跨平台排序差异。在针对已经安装的服务器进行测试时，排序差异也可能是由非 C 区域设置或非默认参数设置（如 work_mem 或规划程序成本参数的自定义值）造成的。
You might see differences in which the same rows are output in a different order than what appears in the expected file. In most cases this is not, strictly speaking, a bug. Most of the regression test scripts are not so pedantic as to use an ORDER BY for every single SELECT, and so their result row orderings are not well-defined according to the SQL specification. In practice, since we are looking at the same queries being executed on the same data by the same software, we usually get the same result ordering on all platforms, so the lack of ORDER BY is not a problem. Some queries do exhibit cross-platform ordering differences, however. When testing against an already-installed server, ordering differences can also be caused by non-C locale settings or non-default parameter settings, such as custom values of work_mem or the planner cost parameters.
因此，如果你看到排序差异，只要该查询没有你的结果所违反的 ORDER BY，就不必担心。不过，请无论如何报告该差异，以便我们以后的版本中向该特定查询添加 ORDER BY 以消除虚假的“失败”结果。
Therefore, if you see an ordering difference, it’s not something to worry about, unless the query does have an ORDER BY that your result is violating. However, please report it anyway, so that we can add an ORDER BY to that particular query to eliminate the bogus “failure” in future releases.
你可能想知道为什么我们不显式地对所有回归测试查询进行排序，以一劳永逸地解决这个问题。原因是那样做会让回归测试变得不那么有用，而不是更有用，因为它们会倾向于使用产生有序结果的查询计划类型，排除了那些不产生有序结果的查询计划类型。
You might wonder why we don’t order all the regression test queries explicitly to get rid of this issue once and for all. The reason is that that would make the regression tests less useful, not more, since they’d tend to exercise query plan types that produce ordered results to the exclusion of those that don’t.
33.2.6. Insufficient Stack Depth #
如果 errors 测试在 select infinite_recurse() 命令处导致服务器崩溃，则表示该平台对进程堆栈大小的限制小于 max_stack_depth 参数指示的大小。这可以通过在更高的堆栈大小限制下运行服务器来修复（对于 max_stack_depth 的默认值，建议为 4MB）。如果您无法做到这一点，另一种方法是减小 max_stack_depth 的值。
If the errors test results in a server crash at the select infinite_recurse() command, it means that the platform’s limit on process stack size is smaller than the max_stack_depth parameter indicates. This can be fixed by running the server under a higher stack size limit (4MB is recommended with the default value of max_stack_depth). If you are unable to do that, an alternative is to reduce the value of max_stack_depth.
在支持 getrlimit() 的平台上，服务器应该自动选择 max_stack_depth 的安全值；所以除非你手动覆盖此设置，此类失败就是可报告的错误。
On platforms supporting getrlimit(), the server should automatically choose a safe value of max_stack_depth; so unless you’ve manually overridden this setting, a failure of this kind is a reportable bug.
33.2.7. The “random” Test #
random 测试脚本旨在生成随机结果。在极少数情况下，这会导致回归测试失败。输入：
The random test script is intended to produce random results. In very rare cases, this causes that regression test to fail. Typing:
diff results/random.out expected/random.out应该只产生一两行差异。除非随机测试重复失败，否则无需担心。
should produce only one or a few lines of differences. You need not worry unless the random test fails repeatedly.
33.2.8. Configuration Parameters #
当针对现有安装运行测试时，一些非默认参数设置会导致测试失败。例如，更改 enable_seqscan 或 enable_indexscan 等参数会导致计划更改，这将影响使用 EXPLAIN 的测试结果。
When running the tests against an existing installation, some non-default parameter settings could cause the tests to fail. For example, changing parameters such as enable_seqscan or enable_indexscan could cause plan changes that would affect the results of tests that use EXPLAIN.