Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
e68abfbe
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
e68abfbe
编写于
5月 20, 1999
作者:
T
Tom Lane
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Update SGML docs with some changes I made to test/regress/README
many moons ago, but forgot to put here.
上级
f9e497db
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
85 addition
and
96 deletion
+85
-96
doc/src/sgml/regress.sgml
doc/src/sgml/regress.sgml
+85
-96
未找到文件。
doc/src/sgml/regress.sgml
浏览文件 @
e68abfbe
...
...
@@ -82,15 +82,15 @@ The runtime path is /usr/local/pgsql (other paths are possible).
</Para>
<Para>
The postmaster should be invoked with the system time zone set for
Berkeley, California. This is done automatically by
the regression
test script. However, it does require machine support for the PST8PDT
time zone.
</Para>
<Para>
To verify that your machine does have this support, type
the following:
It was formerly necessary to run the postmaster with system time zone
set to PST, but this is no longer required. You can run
the regression
tests under your normal postmaster configuration. The test script will
set the PGTZ environment variable to ensure that timezone-dependent tests
produce the expected results. However, your system must provide
library support for the PST8PDT time zone, or the timezone-dependent
tests will fail.
To verify that your machine does have this support, type
the following:
<ProgramListing>
setenv TZ PST8PDT
date
...
...
@@ -147,36 +147,15 @@ the following:
like <FileName>ps</FileName> and <FileName>tar</FileName> vary wildly on what options you should use on each
platform. <Emphasis>Use common sense</Emphasis> before typing in these commands.
</Para>
<Procedure>
<Title><ProductName>Postgres</ProductName> Regression Configuration</Title>
<Para>
For a fresh install or upgrading from previous releases of
<ProductName>Postgres</ProductName>:
</Para>
<Step Performance="required">
<Para>
Build the regression test. Type
<ProgramListing>
cd /usr/src/pgsql/src/test/regress
gmake all
</ProgramListing>
</Para>
</Step>
<Step Performance="optional">
<Para>
If you have prevously invoked the regression test, clean up the
working directory with:
<ProgramListing>
cd /usr/src/pgsql/src/test/regress
make clean
</ProgramListing>
</para>
</step>
<Procedure>
<Title><ProductName>Postgres</ProductName> Regression Configuration</Title>
<Step Performance="required">
<Para>
The file /usr/src/pgsql/src/test/regress/README has detailed
...
...
@@ -210,21 +189,41 @@ the following:
</Para>
</Step>
<Step Performance="
required
">
<Step Performance="
optional
">
<Para>
Run the regression tests. Type
If you have previously invoked the regression test, clean up the
working directory with:
<ProgramListing>
cd /usr/src/pgsql/src/test/regress
gmake
runtest
gmake
clean
</ProgramListing>
</Para>
</para>
<Para>
You do not need to type "gmake clean" if this is the first time you
are running the tests.
</Para>
</step>
<Step Performance="required">
<Para>
Build the regression test. Type
<ProgramListing>
cd /usr/src/pgsql/src/test/regress
gmake all
</ProgramListing>
</Para>
</Step>
<Step Performance="required">
<Para>
Run the regression tests. Type
<ProgramListing>
cd /usr/src/pgsql/src/test/regress
gmake runtest
</ProgramListing>
</Para>
</Step>
<Step Performance="required">
...
...
@@ -245,12 +244,13 @@ the following:
<Step Performance="required">
<Para>
After running the tests, type
After running the tests
and examining the results
, type
<ProgramListing>
destroydb regression
cd /usr/src/pgsql/src/test/regress
gmake clean
</ProgramListing>
to recover the temporary disk space used by the tests.
</Para>
</Step>
</procedure>
...
...
@@ -258,48 +258,30 @@ the following:
<Sect1>
<Title>Regression Analysis</Title>
<Para>
<Quote>Failed</Quote> tests may have failed due to slightly different error messages,
math libraries, or output formatting.
<Para>
The results are in files in the ./results directory. These results
can be compared with results in the ./expected directory using 'diff'.
(The test script does this for you, and leaves the differences
in ./regression.diffs.)
</Para>
<Para>
The files might not compare exactly. The test script will report
any difference as a "failure", but the difference might be due
to small cross-system differences in error message wording,
math library behavior, etc.
"Failures" of this type do not indicate a problem with
<ProductName>Postgres</ProductName>.
</Para>
<Para>
For a i686/Linux-ELF platform, no tests failed since this is the
v6.2.1 regression testing reference platform.
</Para>
<Para>
For the SPARC/Linux-ELF platform, using the 970525 beta version of
<ProductName>Postgres</ProductName> v6.2 the following tests "failed":
float8 and geometry "failed" due to minor precision differences in
floating point numbers. select_views produces massively different output,
but the differences are due to minor floating point differences.
</Para>
<Para>
Conclusion? If you do see failures, try to understand the nature of
the differences and then decide if those differences will affect your
intended use of <ProductName>Postgres</ProductName>. However, keep in mind that this is likely
to be the most solid release of <ProductName>Postgres</ProductName> to date, incorporating many
bug fixes from v6.1, and that previous versions of <ProductName>Postgres</ProductName> have been
in use successfully for some time now.
Thus, it is necessary to examine the actual differences for each
"failed" test to determine whether there is really a problem.
The following paragraphs attempt to provide some guidance in
determining whether a difference is significant or not.
</Para>
<Sect2>
<Title>Comparing expected/actual output</Title>
<Para>
The results are in files in the ./results directory. These results
can be compared with results in the ./expected directory using 'diff'.
The files might not compare exactly. The following paragraphs attempt
to explain the differences.
</Para>
</Sect2>
<Sect2>
<Title>Error message differences</Title>
...
...
@@ -337,18 +319,24 @@ the following:
<Title>Date and time differences</Title>
<Para>
On many supported platforms, you can force PostgreSQL to believe that it
is running in the same time zone as Berkeley, California. See details in
the section on how to run the regression tests.
If you do not explicitly set your time zone environment to PST8PDT, then
most of the date and time results will reflect your local time zone and
will fail the regression testing.
There appears to be some systems which do not accept the recommended syntax
for explicitly setting the local time zone rules. Some systems using the
public domain time zone package exhibit minor problems with pre-1970 PDT
times, representing them in PST instead.
Most of the date and time results are dependent on timezone environment.
The reference files are generated for timezone PST8PDT (Berkeley,
California) and there will be apparent failures if the tests are not
run with that timezone setting. The regression test driver sets
environment variable PGTZ to PST8PDT to ensure proper results.
</Para>
<Para>
There appear to be some systems which do not accept the recommended syntax
for explicitly setting the local time zone rules; you may need to use
a different PGTZ setting on such machines.
</Para>
<Para>
Some systems using older timezone libraries fail to apply daylight-savings
corrections to pre-1970 dates, causing pre-1970 PDT times to be displayed
in PST instead. This will result in localized differences in the test
results.
</Para>
</Sect2>
...
...
@@ -357,17 +345,17 @@ the following:
<Title>Floating point differences</Title>
<Para>
Some of the tests involve computing 64-bit (<Type>float8</Type>) number from table
Some of the tests involve computing 64-bit (<Type>float8</Type>) number
s
from table
columns. Differences in results involving mathematical functions of
<Type>float8</Type> columns have been observed. These differences occur where
different operating systems are used on the same platform ie:
BSDI and SOLARIS on Intel/86, and where the same operating system is
used used on different platforms, ie: SOLARIS on SPARC and Intel/86.
<Type>float8</Type> columns have been observed. The float8
and geometry tests are particularly prone to small differences
across platforms.
Human eyeball comparison is needed to determine the real significance
of these differences which are usually 10 places to the right of
the decimal point.
</Para>
<Para>
Some systems signal errors from pow() and exp() differently from
the mechanism expected by the current Postgres code.
</Para>
...
...
@@ -403,7 +391,8 @@ the following:
<Para>
There is at least one test case in random.out which is intended to produce
random results. This causes random to fail the regression testing.
random results. This causes random to fail the regression testing
once in a while.
Typing
<ProgramListing>
diff results/random.out expected/random.out
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录