某些回归测试包含故意构造的非法输入值。错误消息可能来自 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

通常只应产生一两行差异。除非 random 测试反复失败， 否则不必担心。

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