一些回归测试涉及有意输入无效值。错误消息可能来自 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 的测试结果。