回归测试是一套复杂完整的测试， 用来测试嵌入在 PostgreSQL 里的的 SQL 实现。 它同时测试标准 SQL 操作和PostgreSQL的扩展SQL。

运行测试

回归测试可以就一套已经安装好并且在运行的服务器进行测试， 也可以就制作树里面临时安装的服务器进行测试。 详细些说，有"并行"和"串行"运行测试之分。 串行模式顺序运行每个测试，而并行模式启动多个服务器进程，并行地运行一组测试。 并行测试使我们对进程内部通讯和锁的正确工作有足够的信心。 由于历史原因，串行测试通常对一个现存的安装进行测试，而并行测试是"独立"的，不过这么做没有什么技术原因。

制作之后和安装之前运行回归测试，你可以在顶级目录键入

gmake check

（或者你可以进入 src/test/regress 然后在那里运行命令。） 这样将先制作几个辅助文件，比如一些用户定义的触发器函数，然后再运行测试驱动脚本。 最后你会看到类似下面的东西

或者是一些关于某项测试失败的信息。先看看下面的 Section 26.2 然后再想想一个"失败"是否代表严重的错误。

因为这个测试方法运行临时的服务器，所以如果你是 root 用户， 那这个方法不能运行（服务器不能以 root 身份启动）。 如果你已经以 root 身份制作了，你就什么也干不了。 这时候你应该把测试目录的权限变成某个用户可以写， 然后以那个用户身份登陆，再开始测试。比如

如果不是上面那样，安装后就可以运行测试．

如果你配置 PostgreSQL 安装到一个原来安装有老的 PostgreSQL 的目录里，然后在安装新版本之前执行 gmake check， 那么你可能发现测试失败，因为新程序试图使用已经存在的共享库。 （典型的症状是抱怨未定义的符号。） 如果你想在覆盖老版本之间运行测试，那么你需要带着 configure --disable-rpath 制作。 不过，我们不建议你使用这个选项编译作为最终安装的数据库。

并行的回归测试会在你的用户 ID 下启动相当多的进程。 目前，最大的并发数是 20 给并行测试脚本，这意味着 60 个进程： 一个服务器进程，一个psql以及通常还有一个 shell 父进程用于每个测试脚本的psql。 因此，如果你的系统有每用户的进程数限制，那么请确保这个限制至少是 75，否则你就可能在并行测试时看到随机出现的失败。 如果你没有办法提升该限制，那么你可以通过设置 MAX_CONNECTIONS 参数，把大的并行测试程度降低。

在某些系统上，缺省的 Bourne 兼容的 shell（/bin/sh）在管理太多并行的子进程的时候会出乱子。 这可能导致并行测试锁住或者失败。 出现这种情况时，请在命令行上声明另外一个 Bourne 兼容的 shell，比如：

gmake SHELL=/bin/ksh check
如果没有可以替换的 shell，那么你可以象上面那样通过限制连接的个数来绕开。

安装后运行测试， 初始化一个数据区然后启动服务器，像我们在 Chapter 16 里面描述的那样，然后键入

gmake installcheck

或者是跑一个并行测试

gmake installcheck-parallel

该测试将与在本地主机和缺省端口号上运行的服务器进行联接， 除非你用PGHOST和PGPORT环境变量设置为其它值。

有一些正确安装并且具有完整功能的 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 是什么并不重要。要记住回归测试驱动将认为所有这样的文件都是有效的测试结果。

日期和时间差别

如果你在夏时制时间切换的那天，或者是之后一天运行测试，那么在 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 的区域设置，也可能造成排序差异的问题。）

因此，如果你看到一个排序差异，应该不是什么要担心的问题（除非出问题的查询的确使用了 ORDER BY）。 不过，如果有这样的现象，请告诉我们，这样我们就可以在那条查询上加一个 ORDER BY， 这样我们就可以在以后版本里消除着种伪"失败"。

你可能会问，为什么我们不对所有回归测试的 SELECT 进行排序以一次性消灭所有这类问题。 原因是这样做只能让回归测试用处更少，而不是更多，因为它们会试图使用那些生成顺序结果的查询规划，而不再使用那些不排序的查询规划。

"随机"测试

随机测试脚本的目的是测试生成随机结果。 在很罕见的情况下，这会导致回归测试中的随机测试失败。 键入

diff results/random.out expected/random.out

会产生仅仅一行或几行差别。 你不必担心这些，除非随机测试在重复测试中总是失败。