一些回归测试涉及故意无效的输入值。错误消息可能来自 PostgreSQL 代码，也可能来自宿主平台系统例程。在后一种情况下，消息在不同平台之间可能有所不同，但应该反映相似的信息。这些消息差异将导致回归测试“失败”，但可以通过检查来验证。

如果您在初始化时使用的排序区域设置不是 C 区域设置，则服务器在运行时可能会出现由于排序顺序不同而导致的差异和后续的失败。回归测试套件通过提供备用的结果文件来处理此问题，这些文件已知可以处理大量的区域设置。

在使用临时安装方法运行时，要在不同区域设置中运行测试，请在 make 命令行的相应位置传递与区域设置相关的环境变量，例如

make check LANG=de_DE.utf8

（回归测试驱动程序会取消设置 LC_ALL，因此无法使用此变量选择区域设置。）要使用无区域设置，请取消设置所有区域设置相关环境变量（或将其设置为 C），或者使用以下特殊调用：

make check NO_LOCALE=1

在针对现有安装运行测试时，区域设置由现有安装决定。要更改它，请通过将适当的选项传递给 initdb 来使用不同的区域设置初始化数据库集群。

总的来说，建议尝试在生产环境所需的区域设置下运行回归测试，因为这将测试实际在生产环境中使用的与区域设置和编码相关的代码部分。根据操作系统环境，您可能会遇到失败，但至少您会知道在运行实际应用程序时可以预期的区域设置特定的行为。

大多数日期和时间结果取决于时区环境。参考文件是在 America/Los_Angeles 时区生成的，如果测试不是在该时区设置下运行，将会出现明显的失败。回归测试驱动程序将环境变量 PGTZ 设置为 America/Los_Angeles，这通常能确保结果正确。

一些测试涉及从表列计算 64 位浮点数（double precision）。已经观察到涉及 double precision 列数学函数的结果存在差异。float8 和 geometry 测试尤其容易在不同平台之间，甚至在不同的编译器优化设置下出现细微差异。需要通过人工肉眼比对来确定这些差异的实际重要性，这些差异通常出现在小数点右侧的第 10 位。

一些系统将负零显示为 -0，而其他系统仅显示 0。

一些系统对 pow() 和 exp() 的错误处理机制与当前 PostgreSQL 代码期望的机制不同。

您可能会看到相同的行以不同于预期文件中的顺序输出。在大多数情况下，这严格来说并不是一个错误。大多数回归测试脚本并不像严格使用 ORDER BY 来处理每一个 SELECT，因此根据 SQL 规范，它们的输出行顺序并没有被很好地定义。实际上，由于我们是在相同的数据上由相同的软件执行相同的查询，因此在所有平台上我们通常会得到相同的输出顺序，所以缺少 ORDER BY 并不是一个问题。然而，一些查询确实表现出跨平台的排序差异。在针对已安装的服务器进行测试时，排序差异也可能由非 C 区域设置或非默认参数设置引起，例如自定义的 work_mem 值或规划器成本参数。

因此，如果您看到排序差异，这通常不是什么大问题，除非查询确实有一个 ORDER BY 子句，而您的结果违反了它。不过，仍然请报告它，以便我们可以在该特定查询中添加 ORDER BY 子句，以消除未来版本中的错误“失败”。

您可能会想，为什么我们不明确地对所有回归测试查询进行排序以一劳永逸地解决这个问题。原因是这样做会使回归测试的用处减少而不是增加，因为它们倾向于只测试产生排序结果的查询计划类型，而忽略那些不产生排序结果的类型。

如果 errors 测试在 select infinite_recurse() 命令处导致服务器崩溃，则意味着平台对进程堆栈大小的限制小于 max_stack_depth 参数指示的值。这可以通过在更高的堆栈大小限制下运行服务器来解决（建议使用 4MB，默认值为 max_stack_depth）。如果您无法做到这一点，一种替代方法是减小 max_stack_depth 的值。

在支持 getrlimit() 的平台上，服务器应自动选择一个安全的 max_stack_depth 值；因此，除非您手动覆盖了此设置，否则此类故障是一个可报告的 bug。

“random”测试脚本旨在产生随机结果。在极少数情况下，这会导致回归测试失败。输入

diff results/random.out expected/random.out

应该只会产生一两行差异。除非“random”测试反复失败，否则您不必担心。

在针对现有安装运行测试时，某些非默认参数设置可能会导致测试失败。例如，更改 enable_seqscan 或 enable_indexscan 等参数可能会导致计划更改，从而影响使用 EXPLAIN 的测试结果。