Postgresql 中文操作指南

一些回归测试包含有意提供的无效输入值。错误消息可以来自 PostgreSQL 代码或者来自主机平台系统例程。在后一种情况下，消息可能因平台而异，但应反映相似信息。这些消息差异将导致可以经由检查验证的回归测试“失败”。

如果针对在用以 C 以外的排序顺序区域设置初始化的服务器运行测试，则可能由于排序顺序和后续失败而产生差异。回归测试套件通过提供备用结果文件来解决此问题，而这些文件共同处理大量区域设置。

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

（回归测试驱动程序会取消设置 LC_ALL，因此无法使用该变量选择区域设置。）要不用区域设置，请取消设置所有区域设置相关环境变量（或将其设置为 C），或使用以下特殊调用：

在针对现有安装运行测试时，区域设置取决于现有安装。要更改该设置，请将适当的选项传递给 initdb，以在不同区域设置下初始化数据库集群。

总而言之，建议尝试在希望用于生产的区域设置下运行回归测试，因为这将激活生产中实际将要使用的区域设置和编码相关的代码部分。根据操作系统环境，你可能会遇到一些失败，但这样你至少会知道在运行真实应用程序时会产生哪些区域设置特定的行为。

大部分日期和时间结果都依赖于时区环境。参考文件为时区 PST8PDT（加利福尼亚州伯克利市）生成，如果不使用该时区设置运行测试，则会出现明显的失败。回归测试驱动程序会将环境变量 PGTZ 设置为 PST8PDT，这通常可确保获得正确的结果。

一些测试涉及从表列中计算 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 测试脚本旨在生成随机结果。在极少数情况下，这会导致回归测试失败。输入：

应该只产生一两行差异。除非随机测试重复失败，否则无需担心。

当针对现有安装运行测试时，一些非默认参数设置会导致测试失败。例如，更改 enable_seqscan 或 enable_indexscan 等参数会导致计划更改，这将影响使用 EXPLAIN 的测试结果。