Redrock Postgres 搜索 英文
版本: 9.3 / 9.4 / 9.5 / 9.6 / 10 / 11 / 12 / 13 / 14 / 15 / 16 / 17

31.2. 测试评估 #

31.2.1. 错误消息差异
31.2.2. 区域设置差异
31.2.3. 日期和时间差异
31.2.4. 浮点差值
31.2.5. 行顺序差别
31.2.6. 堆栈深度不足
31.2.7. random 测试
31.2.8. 配置参数

某些已正确安装并完全运行的 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 节

31.2.1. 错误消息差异 #

某些回归测试涉及有意提供无效的输入值。错误消息可能来自 PostgreSQL 代码或来自主机平台系统例程。在后一种情况下,消息可能在不同的平台上有所不同,但应该反映类似的信息。这些消息中的差异将会导致出现一个 “失败”” 回归测试,可以通过检查对该测试进行验证。

31.2.2. 语言区域差异 #

如果您针对用除 C 以外的排序顺序区域设置初始化的服务器运行测试,那么由于排序顺序和后续的故障可能会产生差异。回归测试套件通过提供共同能够处理大量区域设置的备用结果文件来处理此问题。

要在使用临时安装方法时在不同区域设置中运行测试,请在 make 命令行上传递合适的区域设置相关环境变量,例如

make check LANG=de_DE.utf8

(回归测试驱动程序取消设置了 LC_ALL,因此不能使用此变量选择区域设置。)要使用无区域设置,请取消设置所有区域设置相关环境变量(或将其设置为 C)或使用以下特殊调用

make check NO_LOCALE=1

针对现有安装运行测试时,区域设置由现有安装确定。要更改,通过将适当的选项传递给 initdb 来用不同区域设置初始化数据库集群。

通常,建议尝试在生产使用所需的区域设置中运行回归测试,因为这将演练实际用于生产的区域设置和编码相关代码部分。根据操作系统环境,您可能会遇到故障,但是,您至少会知道在运行实际应用时预期哪些特定于区域设置的行为。

31.2.3. 日期和时间差异 #

大多数日期和时间结果都依赖于时区环境。参考文件针对时区 America/Los_Angeles 生成,如果未使用此时区设置运行测试,则会发生明显的故障。回归测试驱动程序将环境变量 PGTZ 设置为 America/Los_Angeles,这通常确保了正确的结果。

31.2.4. 浮点差异 #

一些测试涉及从表列中计算 64 位浮点数(double precision)。已观察到涉及 double precision 列的数学函数的结果差异。float8geometry 测试特别容易在不同的平台上产生小的差异,甚至在不同的编译优化设置中也会产生差异。需要通过人工肉眼比较来确定这些差异的真正意义,这些差异通常位于小数点右边的 10 位。

在某些系统中,负零显示为 -0,而在其他系统中则仅仅显示 0

有些系统会使用不同的方式通知 pow()exp() 中的错误,这种机制与当前 PostgreSQL 代码预期的机制不同。

31.2.5. 不同平台上的行顺序差异 #

你可能会看到相同行的输出顺序与预期文件中呈现的顺序不同。在大多数情况下,严格来说这并不是一个错误。大多数回归测试脚本都懒得为每个 SELECT 使用 ORDER BY,所以它们的结果行顺序根据 SQL 规范没有被很好地定义。实际上,由于我们看到相同的数据在相同软件上被相同的查询执行,所以我们通常在所有平台上都得到相同的结果顺序,因此缺少 ORDER BY 并不是一个问题。然而,某些查询确实存在跨平台的顺序差异。在对已安装的服务器进行测试时,顺序差异也可能由非 C 语言环境设置或非默认参数设置(例如,work_mem 或规划器成本参数的自定义值)引起。

因此,如果你看到顺序差异,除非查询确实有一个 ORDER BY 而你的结果违反了它,否则不必担心。然而,无论如何请报告它,以便我们可以在将来的版本中为该特定查询添加一个 ORDER BY 以消除虚假的 失败

你可能会疑惑为什么我们不显式地对所有回归测试查询进行排序,以一劳永逸地解决这个问题。原因在于这将使回归测试的作用降低,而非提高,因为这会倾向于运用会产生有序结果的查询计划类型,而排除了那些不会产生有序结果的查询计划类型。

31.2.6. 堆栈深度不足 #

如果 errors 测试结果以 select infinite_recurse() 命令导致服务器崩溃,则表示平台对进程堆栈大小的限制小于 max_stack_depth 参数所指示的。可以通过在更高的堆栈大小限制下运行服务器来修复此问题(使用 max_stack_depth 的默认值时建议为 4MB)。如果你无法这样做,另一个选择是降低 max_stack_depth 的值。

在支持 getrlimit() 的平台上,服务器应自动选择 max_stack_depth 的安全值;所以,除非你手动覆盖此设置,否则此类的失败是一个可报告的 bug。

31.2.7. random 测试#

random 测试脚本旨在产生随机结果。在非常罕见的情况下,这会导致回归测试失败。键入

diff results/random.out expected/random.out

应该只会产生一行或几行的区别。除非随机测试重复失败,否则你无需担心。

31.2.8. 配置参数#

在对现有安装运行测试时,一些非默认参数设置可能会导致测试失败。例如,更改 enable_seqscanenable_indexscan 等参数会导致计划的更改,从而影响使用 EXPLAIN 的测试结果。