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，例如PG_REGRESS_DIFF_OPTS='-u'。 (或者，如果您愿意，也可以自己运行diff.)
如果由于某种原因某个特定平台为给定测试生成“失败”，但是对输出的检查使您确信结果是有效的，则可以添加一个新的比较文件以在以后的测试运行中使失败报告静音。有关详情，请参见Section 32.3。
32 .2.1. 错误消息差异
一些回归测试涉及故意的无效 Importing 值。错误消息可能来自 PostgreSQL 代码，也可能来自主机平台系统例程。在后一种情况下，消息在平台之间可能有所不同，但应反映相似的信息。消息中的这些差异将导致可以通过检查验证的“失败”回归测试。
32 .2.2. 区域差异
如果您对使用非 C 排序规则 Sequences 语言环境初始化的服务器运行测试，则可能由于排序 Sequences 和后续失败而有所差异。通过提供备用结果文件(已知一起处理大量语言环境)来设置回归测试套件以处理此问题。
要在使用临时安装方法时在不同的语言环境中运行测试，请在make命令行上传递与语言环境相关的适当环境变量，例如：
make check LANG=de_DE.utf8
(回归测试驱动程序取消设置LC_ALL，因此使用该变量选择语言环境无效.)要不使用语言环境，请取消设置所有与语言环境相关的环境变量(或将它们设置为C)或使用以下特殊调用：
make check NO_LOCALE=1
针对现有安装运行测试时，区域设置由现有安装确定。要更改它，请通过将适当的选项传递给initdb来使用其他语言环境初始化数据库集群。
通常，建议尝试在生产环境中使用的语言环境设置中运行回归测试，因为这将行使实际在生产环境中使用的与语言环境和编码相关的代码部分。根据 os 环境的不同，您可能会遇到故障，但是您至少会知道在运行实际应用程序时期望哪些特定于语言环境的行为。
32 .2.3. 日期和时间差异
大多数日期和时间结果取决于时区环境。参考文件是针对时区PST8PDT(加利福尼亚 State 伯克利)生成的，如果未在该时区设置下运行测试，则将导致明显的失败。回归测试驱动程序将环境变量PGTZ设置为PST8PDT，通常可以确保获得正确的结果。
32 .2.4. 浮点数差异
其中一些测试涉及从表列中计算 64 位浮点数(double precision)。已经观察到涉及double precision列的 math 函数的结果差异。 float8和geometry测试在平台之间甚至甚至在不同的编译器优化设置下特别容易出现细微的差异。需要进行人眼比较以确定这些差异的 true 意义，这些差异通常在小数点右边 10 位。
有些系统显示-0表示负零，而其他系统则显示0。
某些系统从pow()和exp()发出的错误 signal 与当前 PostgreSQL 代码所预期的机制不同。
32 .2.5. 行 Sequences 差异
您可能会看到不同之处，即以与预期文件中显示的 Sequences 不同的 Sequences 输出相同的行。严格来讲，在大多数情况下，这不是错误。大多数回归测试脚本都没有足够的趣味性，无法对每个SELECT使用ORDER BY，因此根据 SQL 规范，它们的结果行 Sequences 没有得到很好的定义。实际上，由于我们查看的是由相同软件对相同数据执行的相同查询，因此通常在所有平台上都得到相同的结果排序，因此缺少ORDER BY并不是问题。但是，某些查询确实存在跨平台的排序差异。当针对已经安装的服务器进行测试时，Order 差异也可能是由非 C 语言环境设置或非默认参数设置引起的，例如work_mem的自定义值或计划者成本参数。
因此，如果您看到排序差异，则不必担心，除非查询中确实有一个ORDER BY违反了您的结果。但是，请无论如何都要报告它，以便我们可以在该特定查询中添加ORDER BY来消除将来版本中的虚假“失败”。
您可能想知道为什么我们不明确地对所有回归测试查询进行排序以一劳永逸地解决这个问题。原因是，这会使回归测试的用处不大，而不是更多，因为它们倾向于使用产生有序结果的查询计划类型来排除那些没有结果的查询计划。
32 .2.6. 堆栈深度不足
如果errors测试导致select infinite_recurse()命令导致服务器崩溃，则意味着平台对进程堆栈大小的限制小于max_stack_depth参数指示的限制。可以通过在更高的堆栈大小限制下运行服务器来解决此问题(建议使用 4MB，默认值为max_stack_depth)。如果您无法执行此操作，则可以选择减小max_stack_depth的值。
在支持getrlimit()的平台上，服务器应自动选择max_stack_depth的安全值；因此，除非您手动覆盖了此设置，否则此类失败是可报告的错误。
32 .2.7. “随机”测试
random测试脚本旨在产生随机结果。在极少数情况下，这会导致回归测试失败。Importing：
diff results/random.out expected/random.out
应该只产生一或几行差异。除非随机测试反复失败，否则您不必担心。
32 .2.8. 配置参数
针对现有安装运行测试时，某些非默认参数设置可能会导致测试失败。例如，更改enable_seqscan或enable_indexscan之类的参数可能会导致计划更改，从而影响使用EXPLAIN的测试结果。