Commit e68abfbe authored by Tom Lane's avatar Tom Lane

Update SGML docs with some changes I made to test/regress/README

many moons ago, but forgot to put here.
parent f9e497db
...@@ -82,15 +82,15 @@ The runtime path is /usr/local/pgsql (other paths are possible). ...@@ -82,15 +82,15 @@ The runtime path is /usr/local/pgsql (other paths are possible).
</Para> </Para>
<Para> <Para>
The postmaster should be invoked with the system time zone set for It was formerly necessary to run the postmaster with system time zone
Berkeley, California. This is done automatically by the regression set to PST, but this is no longer required. You can run the regression
test script. However, it does require machine support for the PST8PDT tests under your normal postmaster configuration. The test script will
time zone. set the PGTZ environment variable to ensure that timezone-dependent tests
</Para> produce the expected results. However, your system must provide
library support for the PST8PDT time zone, or the timezone-dependent
<Para> tests will fail.
To verify that your machine does have this support, type To verify that your machine does have this support, type
the following: the following:
<ProgramListing> <ProgramListing>
setenv TZ PST8PDT setenv TZ PST8PDT
date date
...@@ -147,36 +147,15 @@ the following: ...@@ -147,36 +147,15 @@ the following:
like <FileName>ps</FileName> and <FileName>tar</FileName> vary wildly on what options you should use on each 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. platform. <Emphasis>Use common sense</Emphasis> before typing in these commands.
</Para> </Para>
<Procedure>
<Title><ProductName>Postgres</ProductName> Regression Configuration</Title>
<Para> <Para>
For a fresh install or upgrading from previous releases of For a fresh install or upgrading from previous releases of
<ProductName>Postgres</ProductName>: <ProductName>Postgres</ProductName>:
</Para> </Para>
<Step Performance="required"> <Procedure>
<Para> <Title><ProductName>Postgres</ProductName> Regression Configuration</Title>
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>
<Step Performance="required"> <Step Performance="required">
<Para> <Para>
The file /usr/src/pgsql/src/test/regress/README has detailed The file /usr/src/pgsql/src/test/regress/README has detailed
...@@ -210,21 +189,41 @@ the following: ...@@ -210,21 +189,41 @@ the following:
</Para> </Para>
</Step> </Step>
<Step Performance="required"> <Step Performance="optional">
<Para> <Para>
Run the regression tests. Type If you have previously invoked the regression test, clean up the
working directory with:
<ProgramListing> <ProgramListing>
cd /usr/src/pgsql/src/test/regress cd /usr/src/pgsql/src/test/regress
gmake runtest gmake clean
</ProgramListing> </ProgramListing>
</Para> </para>
<Para> <Para>
You do not need to type "gmake clean" if this is the first time you You do not need to type "gmake clean" if this is the first time you
are running the tests. are running the tests.
</Para> </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>
<Step Performance="required"> <Step Performance="required">
...@@ -245,12 +244,13 @@ the following: ...@@ -245,12 +244,13 @@ the following:
<Step Performance="required"> <Step Performance="required">
<Para> <Para>
After running the tests, type After running the tests and examining the results, type
<ProgramListing> <ProgramListing>
destroydb regression destroydb regression
cd /usr/src/pgsql/src/test/regress cd /usr/src/pgsql/src/test/regress
gmake clean gmake clean
</ProgramListing> </ProgramListing>
to recover the temporary disk space used by the tests.
</Para> </Para>
</Step> </Step>
</procedure> </procedure>
...@@ -258,48 +258,30 @@ the following: ...@@ -258,48 +258,30 @@ the following:
<Sect1> <Sect1>
<Title>Regression Analysis</Title> <Title>Regression Analysis</Title>
<Para> <Para>
<Quote>Failed</Quote> tests may have failed due to slightly different error messages, The results are in files in the ./results directory. These results
math libraries, or output formatting. 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 "Failures" of this type do not indicate a problem with
<ProductName>Postgres</ProductName>. <ProductName>Postgres</ProductName>.
</Para> </Para>
<Para> <Para>
For a i686/Linux-ELF platform, no tests failed since this is the Thus, it is necessary to examine the actual differences for each
v6.2.1 regression testing reference platform. "failed" test to determine whether there is really a problem.
</Para> The following paragraphs attempt to provide some guidance in
determining whether a difference is significant or not.
<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.
</Para> </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> <Sect2>
<Title>Error message differences</Title> <Title>Error message differences</Title>
...@@ -337,18 +319,24 @@ the following: ...@@ -337,18 +319,24 @@ the following:
<Title>Date and time differences</Title> <Title>Date and time differences</Title>
<Para> <Para>
On many supported platforms, you can force PostgreSQL to believe that it Most of the date and time results are dependent on timezone environment.
is running in the same time zone as Berkeley, California. See details in The reference files are generated for timezone PST8PDT (Berkeley,
the section on how to run the regression tests. California) and there will be apparent failures if the tests are not
run with that timezone setting. The regression test driver sets
If you do not explicitly set your time zone environment to PST8PDT, then environment variable PGTZ to PST8PDT to ensure proper results.
most of the date and time results will reflect your local time zone and </Para>
will fail the regression testing.
<Para>
There appears to be some systems which do not accept the recommended syntax There appear to be some systems which do not accept the recommended syntax
for explicitly setting the local time zone rules. Some systems using the for explicitly setting the local time zone rules; you may need to use
public domain time zone package exhibit minor problems with pre-1970 PDT a different PGTZ setting on such machines.
times, representing them in PST instead. </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> </Para>
</Sect2> </Sect2>
...@@ -357,17 +345,17 @@ the following: ...@@ -357,17 +345,17 @@ the following:
<Title>Floating point differences</Title> <Title>Floating point differences</Title>
<Para> <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>) numbers from table
columns. Differences in results involving mathematical functions of columns. Differences in results involving mathematical functions of
<Type>float8</Type> columns have been observed. These differences occur where <Type>float8</Type> columns have been observed. The float8
different operating systems are used on the same platform ie: and geometry tests are particularly prone to small differences
BSDI and SOLARIS on Intel/86, and where the same operating system is across platforms.
used used on different platforms, ie: SOLARIS on SPARC and Intel/86.
Human eyeball comparison is needed to determine the real significance Human eyeball comparison is needed to determine the real significance
of these differences which are usually 10 places to the right of of these differences which are usually 10 places to the right of
the decimal point. the decimal point.
</Para>
<Para>
Some systems signal errors from pow() and exp() differently from Some systems signal errors from pow() and exp() differently from
the mechanism expected by the current Postgres code. the mechanism expected by the current Postgres code.
</Para> </Para>
...@@ -403,7 +391,8 @@ the following: ...@@ -403,7 +391,8 @@ the following:
<Para> <Para>
There is at least one test case in random.out which is intended to produce 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 Typing
<ProgramListing> <ProgramListing>
diff results/random.out expected/random.out diff results/random.out expected/random.out
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment