一些回归测试涉及有意的无效输入值。错误消息可能来自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参数所指示的大小。 这可以通过在更高的堆栈大小限制下运行服务器来解决（建议使用4MB的max_stack_depth默认值）。 如果您无法做到这一点，另一种方法是减小max_stack_depth的值。

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

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

diff results/random.out expected/random.out

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

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