pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
目录
摘要
回归测试的说明与分析
回归测试是针对PostgreSQL中 SQL 实现的一套全面测试。它们既测试标准 SQL 操作，也测试 PostgreSQL的扩展能力。这个测试套件最初由 Jolly Chen 和 Andrew Yu 开发，并经 Marc Fournier 和 Thomas Lockhart 大幅修订和重新打包。从 PostgreSQL 6.1 起 回归测试对每个正式发行版都是最新的。
回归测试既可以针对一个已安装并正在运行的服务器运行，也可以使用构建树中的一个临时安装来运行。此外，还有“并行”和“顺序”两种运行测试的模式。顺序方法依次运行每个测试脚本，而并行方法会启动多个服务器进程来并行运行成组的测试。并行测试可以让人确信进程间通信和锁机制工作正常。由于历史原因，顺序测试通常针对现有安装运行，而并行方法针对临时安装运行，但这并没有技术上的原因。
要在构建之后、安装之前运行回归测试，在顶层目录中键入
$gmake check
（或者你可以切换到 src/test/regress 并在那里运行该命令。）这会先构建若干辅助文件，例如平台相关的“expected”文件和一些示例用户定义触发器函数，然后运行测试驱动脚本。最后你应当看到类似
======================
All 76 tests passed.
======================
的输出，或者一条关于哪些测试失败的说明。更多信息见下文第 12.1 节。
由于这种测试方法运行的是一个临时服务器，当你以 root 用户操作时它将无法工作（服务器不会以 root 启动）。如果你已经以 root 完成了构建，不必从头再来。只需让回归测试目录可被其他用户写入，以该用户登录，然后重新启动测试。例如
root#chmod -R a+w src/test/regressroot#su - joeuserjoeuser$gmake check
（这里唯一可能的“安全风险”是其他用户可能背着你篡改回归测试结果。管理用户权限时请运用常识。）
或者，在安装之后运行测试。
在某些系统上，默认的 Bourne 兼容 shell（/bin/sh）在要并行管理太多子进程时会出问题。这可能导致并行测试运行锁死或失败。在这种情况下，在命令行上指定一个不同的 Bourne 兼容 shell，例如：
$gmake SHELL=/bin/ksh check
要在安装之后运行测试（见第 1 章），初始化一个数据区域并启动服务器，如第 3 章所述，然后键入
$gmake installcheck
除非 PGHOST 和 PGPORT 环境变量另有指示，测试将期望在本地主机和默认端口号上连接服务器。
某些安装正确且功能完备的PostgreSQL实例， 可能会因为平台特有因素而在部分回归测试中“失败”，例如浮点 表示和时区支持的差异。目前这些测试是通过把输出与参考系统生成的输出做 简单的diff比较来评估的，因此结果会对细微的系统差异 很敏感。报告某项测试“失败”时，请务必检查预期结果与实际结果 之间的差异；你可能会发现这些差异并不重要。尽管如此，我们仍努力在所有 受支持平台上维护准确的参考文件，因此原则上应期待所有测试都能通过。
回归测试的实际输出位于src/test/regress/results目录中的文件里。测试脚本使用diff把每个输出文件与存储在src/test/regress/expected目录中的参考输出进行比较。任何差异都会保存到src/test/regress/regression.diffs中供你检查。（如果愿意，也可以自己运行diff。）
某些回归测试包含故意构造的非法输入值。错误消息可能来自 PostgreSQL代码，也可能来自宿主平台的系统例程。 在后一种情况下，消息会因平台而异，但应反映相近的信息。这类消息差异 会导致回归测试显示为“失败”，但可以通过检查确认其有效性。
这些测试期望在普通的 “C” locale 中运行。当你针对临时安装运行测试时，这应当不会造成任何问题，因为回归测试驱动程序会确保以 C locale 启动服务器。但是，如果你针对一个使用非 C locale 设置的已安装服务器运行测试，可能会看到由字符串排序规则、数字和货币值格式等方面的差异引起的问题。
在某些 locale 中，产生的差异很小，很容易通过检查确认。但是，在改变了数字值格式规则的 locale 中（通常是通过交换逗号和小数点的用法），某些数据值的输入将会失败，从而在测试后面本应使用这些缺失数据值的地方引起大量差异。
大多数日期和时间结果依赖于时区环境。参考文件是为时区 PST8PDT（加利福尼亚州伯克利）生成的，如果测试不使用该时区设置运行，就会出现明显的失败。回归测试驱动程序会把环境变量 PGTZ 设置为 PST8PDT 以确保正确的结果。但是，你必须为 PST8PDT 时区提供系统库支持，否则依赖时区的测试将会失败。要验证你的机器确实支持这一点，请键入：
$env TZ=PST8PDT date
上面的命令应当以 PST8PDT 时区返回当前系统时间。如果 PST8PDT 时区不可用，你的系统可能返回的是 GMT 时间。如果缺少 PST8PDT 时区，你可以显式设置时区规则：
PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
有些系统似乎不接受显式设置本地时区规则的推荐语法；在这类机器上你可能需要使用不同的 PGTZ 设置。
一些使用较老时区库的系统无法对 1970 年之前的日期应用夏令时修正，导致 1970 年前的 PDT 时间显示为 PST。这会导致测试结果中出现局部差异。
如果你在一个夏令时切换日或其前一天或后一天运行 “timestamp” 测试，其中少数查询会失败。这些查询假定昨天午夜、今天午夜和明天午夜之间的间隔正好是二十四小时——如果其间夏令时生效或失效，这就是错误的。
某些测试涉及从表列计算 64 位（double precision）数。已经观察到涉及double precision列数学函数的结果存在差异。float8 和 geometry 测试尤其容易在不同平台之间、甚至在不同编译器优化设置下出现微小差异。需要人工目测比较来确定这些差异的真实意义，它们通常出现在小数点右侧第 10 位。
某些系统对pow()和exp() 发出错误的方式，与当前PostgreSQL代码所 预期的机制不同。
若干测试涉及对加利福尼亚州奥克兰/伯克利街道地图地理数据的操作。地图数据被表示为多边形，其顶点用一对 double precision数（十进制纬度和经度）表示。首先创建一些表并装入地理数据，然后创建一些使用多边形相交操作符（##）连接两个表的视图，再对视图做一次 select。
在比较不同平台的结果时，差异出现在小数点右侧第 2 或第 3 位。出现这些问题的 SQL 语句是：
SELECT * from street; SELECT * from iexit;
你可能会看到这样的差异：同样的元组在输出中的顺序与预期文件中的顺序不同。 在大多数情况下，严格说来这并不是缺陷。大多数回归测试脚本并没有细致到 为每一个SELECT都使用ORDER BY， 因此按 SQL 规范，它们的结果元组顺序并没有良好定义。实际上，由于我们看到的 是同一软件在同一数据上执行相同查询，通常在所有平台上都会得到相同的结果 顺序，所以缺少ORDER BY并不是问题。不过，有些查询 确实会表现出跨平台的顺序差异。（非 C 区域设置也可能触发顺序差异。）
因此，如果你看到顺序差异，一般无需担心，除非查询确实包含 ORDER BY而你的结果违反了它。不过，仍请报告该问题， 这样我们可以为那个特定查询加上ORDER BY，以在后续 版本中消除这种虚假的“失败”。
你可能会好奇，为什么我们不显式地对所有回归测试 SELECT 排序，从而一劳永逸地 解决这个问题。原因在于，那样反而会降低回归测试的价值，因为测试会倾向于 覆盖能产生有序结果的查询计划类型，而排除那些不能产生有序结果的计划类型。
“random” 测试脚本中至少有一种情况旨在产生随机结果。这会使 random 回归测试偶尔（也许每五到十次尝试一次）失败。键入
diff results/random.out expected/random.out
应当只产生一行或几行差异。除非随机测试在反复尝试中总是失败，否则不必担心。（另一方面，如果在回归测试的多次尝试中随机测试从未被报告失败，你可能确实应该担心。）
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。