一些回归测试涉及故意的无效输入值。错误消息可能来自 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 代码预期的方式不同。

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

因此，如果您看到排序差异，则不必担心，除非查询确实具有您结果违反的 ORDER BY。但是，请仍然报告它，以便我们可以向该特定查询添加 ORDER BY，以消除未来版本中的虚假“失败”。

您可能想知道为什么我们不明确地对所有回归测试查询进行排序以一劳永逸地解决此问题。原因是这将使回归测试变得更少有用，而不是更多，因为它们倾向于练习产生有序结果的查询计划类型，而排斥那些不产生有序结果的查询计划类型。

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

在支持 getrlimit() 的平台上，服务器应该会自动选择一个安全的 max_stack_depth 值；因此，除非您手动覆盖此设置，否则此类故障应作为可报告的错误进行处理。

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

diff results/random.out expected/random.out

应该只产生一行或几行差异。除非随机测试反复失败，否则您无需担心。

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