某些已正确安装并完全运行的 PostgreSQL 安装可能无法通过这些回归测试(“失败”),这是因为出现类似浮点表示和消息文字这样的特定于平台的问题。当前正在使用简单的 diff
比较对测试进行评估,该比较与在参考系统上生成的输出进行比较,因此结果受细微系统差异的影响很大。当某个测试报告为 “失败”” 时,请务必检查预期结果和实际结果之间的差异;您可能会发现差异并不显著。尽管如此,我们仍然竭尽全力在所有受支持的平台上保存准确的参考文件,因此可以预期所有测试都能通过。
回归测试的实际输出位于 src/test/regress/results
目录中的文件。测试脚本使用 diff
将每个输出文件与存储在 src/test/regress/expected
目录中的参考输出进行比较。任何差异都将被保存在 src/test/regress/regression.diffs
中以便您进行检查。(在运行核心测试以外的测试套件时,这些文件当然出现在相应的子目录中,而不是 src/test/regress
中。)
如果您不喜欢默认使用的 diff
选项,请设置环境变量 PG_REGRESS_DIFF_OPTS
,例如 PG_REGRESS_DIFF_OPTS='-c'
。(或者,如果您愿意,也可以自己运行 diff
。)
如果由于某种原因特定的平台对某项给定的测试生成 “失败”” 结果,但检查输出后您确信该结果有效,您可以添加一个新的比较文件,以便在将来的测试运行中消除失败报告。有关详细信息,请参见 第 31.3 节。
某些回归测试涉及有意提供无效的输入值。错误消息可能来自 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
的安全值;所以,除非你手动覆盖此设置,否则此类的失败是一个可报告的 bug。
random
测试脚本旨在产生随机结果。在非常罕见的情况下,这会导致回归测试失败。键入
diff results/random.out expected/random.out
应该只会产生一行或几行的区别。除非随机测试重复失败,否则你无需担心。
在对现有安装运行测试时,一些非默认参数设置可能会导致测试失败。例如,更改 enable_seqscan
或 enable_indexscan
等参数会导致计划的更改,从而影响使用 EXPLAIN
的测试结果。