有一些正确安装并且具有完整功能的 PostgreSQL可能会在一些回归测试中"失效"， 这些主要是因为浮点数的形式和时区支持的问题。 目前的测试只是简单的用 diff 与参考系统的输出进行比较， 因而对一些细小的系统区别很敏感。 当一项测试报告"失败"时，只要检查一下预期和实际的结果， 你就会发现区别并不大。 当然，我们仍然在努力维护所有我们支持的平台的准确的参考文件， 这样我们就可以假定所有测试都通过。
回归测试的实际输出是在 src/test/regress/results 目录里的文件里。测试脚本使用 diff 以比较每个输出文件和存放在 src/test/regress/expected 目录里的参考输出。任何区别都存放在 src/test/regress/regression.diffs 里面供你检查。（或者如果你愿意的话，你也可以自己运行 diff。）
有一些回归测试涉及到有意的非法输入值。 错误信息可能会来自 PostgreSQL 代码或来自主机平台系统过程。 对于后者，信息可能在平台之间区别比较大，但应该反映相似的信息。 这些信息上的差别将会导致一个"失败"的回归测试， 我们可以通过检查文件发现这一点。
如果你在一台已经安装好了的服务器上运行测试，而该服务器是用一种非 C 的区域设置初始化的， 那么可能因为有排序顺序和其它类似的差别导致的失败。回归测试套件处理这种问题的方法是提供可选的结果文件， 这些文件一起处理一大堆的区域。比如，对于 char 测试， 预期的文件 char.out 处理C和POSIX区域， 而文件 char_1.out 处理许多其它区域。 回归测试驱动将自动选取最接近的文件进行成功检查以及计算失败差别。 （这就意味着回归测试不能检测该结果对于配置的区域是否合适。 该测试将简单地选取一个运转得最好的文件。）
如果由于某些原因，现有的预期文件无法覆盖一些区域，那么你可以增加一个新文件。命名模式是 testname_digit.out。 实际的 digit 是什么并不重要。要记住回归测试驱动将认为所有这样的文件都是有效的测试结果。 如果测试结果是平台相关的，那么应该使用在 Section 27.3 里描述的技巧。
如果你在夏时制时间切换的那天，或者是之后一天运行测试，那么在 horology 测试中的几个查询会失败，这些查询假设在昨日午夜，今日午夜和明日午夜之间的差距正好时 24 小时 -- 如果在夏时制切换的时候这个数值时错误的。
注意: 因为使用了 USA 的夏时制规则，所以这些问题总是出现在四月的第一个星期天， 和十月的最后一个星期六，以及它们后面的那个星期一 — 不管你居住的地方的夏时制是从什么时候开始的。 还要注意这个问题在太平洋时间（UTC-7或者UTC-8）的午夜出现或者消失， 而不是你本地时间的午夜。因此，这些问题可能在星期六的晚上出现， 或者一直到星期二的大部分时间都存在，具体现象取决于你居住的地方。
大多数日期和时间结果依赖于时区环境变量。参考文件是为时区 PST8PDT （伯克利，加州）准备的，因而如果测试没有设置为那个时区是显然会失败的。 回归测试的驱动器把环境变量 PGTZ 设置为 PST8PDT，基本可以保证正确的测试。
有些测试涉及到对表中的数据列进行 64位浮点数（double precision）计算的问题。 我们观察了涉及到计算double precision字段的数学函数的结果的差别。 float8和geometry（几何类型）测试尤其容易在不同平台之间产生小差别。 这时需要肉眼对这些差别进行比较， 以判断这些差别究竟有多大，我们发现是在小数点右边10位数。
有些系统把负零显示为 -0，而其它的只是显示 0。
有些系统在pow()和exp()
出错时产生的信号与目前 Postgres 代码里期望的机制不一样。
你可能会看见同样的行以与预期文件的不同的顺序输出。在大多数情况下， 严格说来这不算臭虫。大多数回归测试脚本都不会迂腐到在每个SELECT中都使用ORDER BY的地步， 因此根据 SQL 规范里的词汇的说明，它们的结果集的顺序并非定义得非常好的。尤其是因为我们是在同样的数据上运行同样的查询， 因此我们在所有平台上通常都获得同样的结果， 因此即使缺少ORDER BY也不算什么大问题。 不过有些查询的确存在跨平台的排序问题。 在测试一台已经安装的服务器的时候，排序的差别也可能因为非 C 的区域设置， 或者非缺省的参数设置，比如客户自己设置的 work_mem 或者规划器开销参数设置受影响。
因此，如果你看到一个排序差异，应该不是什么要担心的问题（除非出问题的查询的确使用了 ORDER BY）。 不过，如果有这样的现象，请告诉我们，这样我们就可以在那条查询上加一个 ORDER BY， 这样我们就可以在以后版本里消除着种伪"失败"。
你可能会问，为什么我们不对所有回归测试的 SELECT 进行排序以一次性消灭所有这类问题。 原因是这样做只能让回归测试用处更少，而不是更多，因为它们会试图使用那些生成顺序结果的查询规划， 而不再使用那些不排序的查询规划。
如果 errors 测试导致在 select infinite_recurse() 命令的时候服务器崩溃，这就意味着平台对进程堆栈的限制小于 max_stack_depth 参数指出的值。我们可以通过在更高的堆栈限制的数值上运行 postmaster 绕开这个问题 （缺省的 max_stack_depth 下，建议数值是 4M）。 如果你无法这么做，那么另外一个方法是减少 max_stack_depth 的值。
随机测试脚本的目的是测试生成随机结果。 在很罕见的情况下，这会导致回归测试中的随机测试失败。 键入
diff results/random.out expected/random.out
会产生仅仅一行或几行差别。 你不必担心这些，除非随机测试在重复测试中总是失败。