mirror of https://github.com/postgres/postgres
Readd test/regress/README file, this time with a well-defined and simple
rule to remake it when necessary.
This commit is contained in:
Peter Eisentraut
parent
35b7601b04
commit
4e77b4a548
|
|
@ -8,7 +8,7 @@
|
|||
#
|
||||
#
|
||||
# IDENTIFICATION
|
||||
# $Header: /cvsroot/pgsql/doc/src/sgml/Makefile,v 1.39 2001/09/18 12:08:26 petere Exp $
|
||||
# $Header: /cvsroot/pgsql/doc/src/sgml/Makefile,v 1.40 2001/09/21 18:37:05 petere Exp $
|
||||
#
|
||||
#----------------------------------------------------------------------------
|
||||
|
||||
|
|
@ -148,10 +148,10 @@ $(addsuffix .tex, $(ALLBOOKS)): %.tex: %.sgml $(ALLSGML) stylesheet.dsl
|
|||
|
||||
JADE.text = $(JADE) $(JADEFLAGS) $(SGMLINCLUDE) -c $(CATALOG) -d stylesheet.dsl -i output-text -t sgml
|
||||
|
||||
INSTALL HISTORY: % : %.html
|
||||
INSTALL HISTORY regress_README: % : %.html
|
||||
@echo "|";\
|
||||
echo "| You should now take \`$<', save it as a text file in Netscape,";\
|
||||
echo "| and put it in place of the existing \`$@' file.";\
|
||||
echo "| You should now take '$<', save it as a text file in Netscape,";\
|
||||
echo "| and put it in place of the existing '$@' file.";\
|
||||
echo "|"
|
||||
|
||||
INSTALL.html: standalone-install.sgml installation.sgml
|
||||
|
|
@ -163,6 +163,13 @@ HISTORY.html: release.sgml
|
|||
$(JADE.text) -V nochunks tempfile_HISTORY.sgml >$@
|
||||
rm tempfile_HISTORY.sgml
|
||||
|
||||
regress_README.html: regress.sgml
|
||||
( echo '<!doctype chapter PUBLIC "-//OASIS//DTD DocBook V3.1//EN" ['; \
|
||||
echo '<!entity % standalone-ignore "IGNORE"> ]>'; \
|
||||
cat $< ) >tempfile_regress_README.sgml
|
||||
$(JADE.text) -V nochunks tempfile_regress_README.sgml >$@
|
||||
rm tempfile_regress_README.sgml
|
||||
|
||||
|
||||
##
|
||||
## Check
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.33 2001/09/13 15:55:22 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/docguide.sgml,v 1.34 2001/09/21 18:37:05 petere Exp $ -->
|
||||
|
||||
<appendix label="DG2" id="docguide">
|
||||
<title>Documentation</title>
|
||||
|
|
@ -901,21 +901,9 @@ exit
|
|||
|
||||
<para>
|
||||
The file <filename>HISTORY</filename> can be created similarly,
|
||||
using the command <userinput>gmake HISTORY</userinput>. The table
|
||||
of contents should be removed manually from the resulting text
|
||||
file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Since it does not change very often, the generation of the file
|
||||
<filename>src/test/regress/README</filename> is not fully
|
||||
automated. After building the <acronym>HTML</acronym> version of
|
||||
the <citetitle>Administrator's Guide</citetitle>, convert the
|
||||
resulting files <filename>regress.html</filename> and
|
||||
<filename>regress-platform.html</filename> to text, using
|
||||
<productname>Netscape</productname>. Then paste the text files
|
||||
together and edit them to taste (e.g., remove the navigation
|
||||
bars, remove the references to other chapters).
|
||||
using the command <userinput>gmake HISTORY</userinput>. For the
|
||||
file <filename>src/test/regress/README</filename> the command is
|
||||
<userinput>gmake regress_README</userinput>.
|
||||
</para>
|
||||
|
||||
<!--
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.15 2001/09/02 23:27:49 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/filelist.sgml,v 1.16 2001/09/21 18:37:05 petere Exp $ -->
|
||||
|
||||
<!entity history SYSTEM "history.sgml">
|
||||
<!entity info SYSTEM "info.sgml">
|
||||
|
|
@ -100,6 +100,11 @@
|
|||
<!entity sources SYSTEM "sources.sgml">
|
||||
<!entity nls SYSTEM "nls.sgml">
|
||||
|
||||
<!-- see standalone-install.sgml about these -->
|
||||
<!entity % flattext-install-ignore "INCLUDE">
|
||||
<!entity % flattext-install-include "IGNORE">
|
||||
<!--
|
||||
Some parts of the documentation are also source for some plain-text
|
||||
files used during installation. To selectively ignore or include
|
||||
some parts (e.g., external xref's) when generating these files we use
|
||||
these parameter entities. See also standalone-install.sgml.
|
||||
-->
|
||||
<!entity % standalone-ignore "INCLUDE">
|
||||
<!entity % standalone-include "IGNORE">
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.56 2001/09/16 16:11:09 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v 1.57 2001/09/21 18:37:05 petere Exp $ -->
|
||||
|
||||
<chapter id="installation">
|
||||
<title><![%flattext-install-include[<productname>PostgreSQL</>]]>
|
||||
<title><![%standalone-include[<productname>PostgreSQL</>]]>
|
||||
Installation Instructions</title>
|
||||
|
||||
<indexterm zone="installation">
|
||||
|
|
@ -27,8 +27,8 @@ su - postgres
|
|||
/usr/local/pgsql/bin/psql test
|
||||
</synopsis>
|
||||
The long version is the rest of this
|
||||
<![%flattext-install-include;[document.]]>
|
||||
<![%flattext-install-ignore;[chapter.]]>
|
||||
<![%standalone-include;[document.]]>
|
||||
<![%standalone-ignore;[chapter.]]>
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
|
|
@ -156,7 +156,7 @@ su - postgres
|
|||
</para>
|
||||
</sect1>
|
||||
|
||||
<![%flattext-install-ignore;[
|
||||
<![%standalone-ignore;[
|
||||
<sect1 id="install-getsource">
|
||||
<title>Getting The Source</title>
|
||||
|
||||
|
|
@ -221,8 +221,8 @@ su - postgres
|
|||
foreign keys), then use the <option>-o</option> option when running
|
||||
<command>pg_dumpall</>. <command>pg_dumpall</command> does not
|
||||
save large objects. Check
|
||||
<![%flattext-install-include[the <citetitle>Administrator's Guide</>]]>
|
||||
<![%flattext-install-ignore[<xref linkend="backup-dump-caveats">]]>
|
||||
<![%standalone-include[the <citetitle>Administrator's Guide</>]]>
|
||||
<![%standalone-ignore[<xref linkend="backup-dump-caveats">]]>
|
||||
if you need to do this.
|
||||
</para>
|
||||
|
||||
|
|
@ -290,8 +290,8 @@ su - postgres
|
|||
<para>
|
||||
You can also install the new version in parallel with the old one
|
||||
to decrease the downtime. These topics are discussed at length in
|
||||
<![%flattext-install-include[the <citetitle>Administrator's Guide</>,]]>
|
||||
<![%flattext-install-ignore[<xref linkend="migration">,]]>
|
||||
<![%standalone-include[the <citetitle>Administrator's Guide</>,]]>
|
||||
<![%standalone-ignore[<xref linkend="migration">,]]>
|
||||
which you are encouraged
|
||||
to read in any case.
|
||||
</para>
|
||||
|
|
@ -531,8 +531,8 @@ su - postgres
|
|||
<listitem>
|
||||
<para>
|
||||
Enables single-byte character set recode support. See
|
||||
<![%flattext-install-include[the <citetitle>Administrator's Guide</citetitle>]]>
|
||||
<![%flattext-install-ignore[<xref linkend="recode">]]> about this feature.
|
||||
<![%standalone-include[the <citetitle>Administrator's Guide</citetitle>]]>
|
||||
<![%standalone-ignore[<xref linkend="recode">]]> about this feature.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -544,8 +544,8 @@ su - postgres
|
|||
Allows the use of multibyte character encodings. This is
|
||||
primarily for languages like Japanese, Korean, and Chinese.
|
||||
Read
|
||||
<![%flattext-install-include[the <citetitle>Administrator's Guide</citetitle>]]>
|
||||
<![%flattext-install-ignore[<xref linkend="multibyte">]]>
|
||||
<![%standalone-include[the <citetitle>Administrator's Guide</citetitle>]]>
|
||||
<![%standalone-ignore[<xref linkend="multibyte">]]>
|
||||
for details.
|
||||
</para>
|
||||
</listitem>
|
||||
|
|
@ -902,10 +902,10 @@ All of PostgreSQL is successfully made. Ready to install.
|
|||
</screen>
|
||||
It is possible that some tests fail, due to differences in error
|
||||
message wording or floating point results.
|
||||
<![%flattext-install-include[The file
|
||||
<![%standalone-include[The file
|
||||
<filename>src/test/regress/README</> and the
|
||||
<citetitle>Administrator's Guide</citetitle> contain]]>
|
||||
<![%flattext-install-ignore[<xref linkend="regress"> contains]]>
|
||||
<![%standalone-ignore[<xref linkend="regress"> contains]]>
|
||||
detailed information about interpreting the test results. You can
|
||||
repeat this test at any later time by issuing the same command.
|
||||
</para>
|
||||
|
|
@ -1127,7 +1127,7 @@ MANPATH=$MANPATH:/usr/local/pgsql/man
|
|||
</sect1>
|
||||
|
||||
|
||||
<![%flattext-install-include;[
|
||||
<![%standalone-include;[
|
||||
<sect1 id="install-getting-started">
|
||||
<title>Getting Started</title>
|
||||
|
||||
|
|
@ -1634,8 +1634,8 @@ gunzip -c user.ps.gz \
|
|||
<entry>2001-03-26, Magnus Hagander (<email>mha@sollentuna.net</email>)</entry>
|
||||
<entry>
|
||||
client-side libraries (<application>libpq</> and <application>psql</>) or ODBC/JDBC, no server-side;
|
||||
<![%flattext-install-include[see Administrator's Guide]]>
|
||||
<![%flattext-install-ignore[see <xref linkend="install-win32">]]>
|
||||
<![%standalone-include[see Administrator's Guide]]>
|
||||
<![%standalone-ignore[see <xref linkend="install-win32">]]>
|
||||
for instructions
|
||||
</entry>
|
||||
</row>
|
||||
|
|
|
|||
|
|
@ -1,13 +1,10 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.20 2001/09/11 02:24:52 ishii Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.21 2001/09/21 18:37:05 petere Exp $ -->
|
||||
|
||||
<chapter id="regress">
|
||||
<title id="regress-title">Regression Tests</title>
|
||||
|
||||
<abstract>
|
||||
<para>
|
||||
Regression test instructions and analysis
|
||||
</para>
|
||||
</abstract>
|
||||
<sect1 id="regress-intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
The regression tests are a comprehensive set of tests for the SQL
|
||||
|
|
@ -20,6 +17,11 @@
|
|||
the regression tests are current for every official release.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="regress-run">
|
||||
<title>Running the Tests</title>
|
||||
|
||||
<para>
|
||||
The regression test can be run against an already installed and
|
||||
running server, or using a temporary installation within the build
|
||||
|
|
@ -97,9 +99,9 @@
|
|||
</tip>
|
||||
|
||||
<para>
|
||||
To run the tests after installation (see <xref
|
||||
linkend="installation">), initialize a data area and start the
|
||||
server, as explained in <xref linkend="runtime">, then type
|
||||
To run the tests after installation<![%standalone-ignore;[ (see <xref linkend="installation">)]]>,
|
||||
initialize a data area and start the
|
||||
server, <![%standalone-ignore;[as explained in <xref linkend="runtime">, ]]> then type
|
||||
<screen>
|
||||
<prompt>$ </prompt><userinput>gmake installcheck</userinput>
|
||||
</screen>
|
||||
|
|
@ -107,6 +109,7 @@
|
|||
default port number, unless directed otherwise by <envar>PGHOST</envar> and <envar>PGPORT</envar>
|
||||
environment variables.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="regress-evaluation">
|
||||
<title>Test Evaluation</title>
|
||||
|
|
@ -255,7 +258,7 @@ PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
|
|||
|
||||
<para>
|
||||
Several of the tests involve operations on geographic data about
|
||||
the Oakland/Berkeley, CA street map. The map data is expressed as
|
||||
the Oakland/Berkeley, California street map. The map data is expressed as
|
||||
polygons whose vertices are represented as pairs of <type>double
|
||||
precision</type> numbers (decimal latitude and
|
||||
longitude). Initially, some tables are created and loaded with
|
||||
|
|
@ -277,15 +280,15 @@ SELECT * from iexit;
|
|||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Tuple ordering differences</title>
|
||||
<title>Row ordering differences</title>
|
||||
|
||||
<para>
|
||||
You might see differences in which the same tuples are output in a
|
||||
You might see differences in which the same rows are output in a
|
||||
different order than what appears in the expected file. In most cases
|
||||
this is not, strictly speaking, a bug. Most of the regression test
|
||||
scripts are not so pedantic as to use an ORDER BY for every single
|
||||
SELECT, and so their result tuple orderings are not well-defined
|
||||
according to the letter of the SQL spec. In practice, since we are
|
||||
SELECT, and so their result row orderings are not well-defined
|
||||
according to the letter of the SQL specification. In practice, since we are
|
||||
looking at the same queries being executed on the same data by the same
|
||||
software, we usually get the same result ordering on all platforms, and
|
||||
so the lack of ORDER BY isn't a problem. Some queries do exhibit
|
||||
|
|
@ -325,12 +328,13 @@ diff results/random.out expected/random.out
|
|||
not worry unless the random test always fails in repeated
|
||||
attempts. (On the other hand, if the random test is
|
||||
<emphasis>never</emphasis> reported to fail even in many trials
|
||||
of the regress tests, you probably <emphasis>should</emphasis>
|
||||
of the regression tests, you probably <emphasis>should</emphasis>
|
||||
worry.)
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<![%standalone-ignore;[
|
||||
<!-- We might want to move the following section into the developer's guide. -->
|
||||
<sect1 id="regress-platform">
|
||||
<title>Platform-specific comparison files</title>
|
||||
|
|
@ -384,6 +388,7 @@ horology/hppa=horology-no-DST-before-1970
|
|||
</para>
|
||||
|
||||
</sect1>
|
||||
]]>
|
||||
|
||||
</chapter>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/standalone-install.sgml,v 2.2 2000/11/30 21:44:07 petere Exp $ -->
|
||||
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/standalone-install.sgml,v 2.3 2001/09/21 18:37:05 petere Exp $ -->
|
||||
|
||||
<!--
|
||||
This file helps in generating the INSTALL text file that lives in the
|
||||
|
|
@ -32,8 +32,8 @@ equivalent of C's #ifdef and friends. The other end of this is in
|
|||
installation.sgml.
|
||||
-->
|
||||
|
||||
<!entity % flattext-install-ignore "IGNORE">
|
||||
<!entity % flattext-install-include "INCLUDE">
|
||||
<!entity % standalone-ignore "IGNORE">
|
||||
<!entity % standalone-include "INCLUDE">
|
||||
|
||||
<!--
|
||||
When you're building the Administrator's Guide, you want to flip the
|
||||
|
|
|
|||
|
|
@ -0,0 +1,243 @@
|
|||
Regression Tests
|
||||
|
||||
Introduction
|
||||
|
||||
The regression tests are a comprehensive set of tests for the SQL
|
||||
implementation in PostgreSQL. They test standard SQL operations as well as
|
||||
the extended capabilities of PostgreSQL. The test suite was originally
|
||||
developed by Jolly Chen and Andrew Yu, and was extensively revised and
|
||||
repackaged by Marc Fournier and Thomas Lockhart. From PostgreSQL 6.1 onward
|
||||
the regression tests are current for every official release.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Running the Tests
|
||||
|
||||
The regression test can be run against an already installed and running
|
||||
server, or using a temporary installation within the build tree.
|
||||
Furthermore, there is a "parallel" and a "sequential" mode for running the
|
||||
tests. The sequential method runs each test script in turn, whereas the
|
||||
parallel method starts up multiple server processes to run groups of tests
|
||||
in parallel. Parallel testing gives confidence that interprocess
|
||||
communication and locking are working correctly. For historical reasons, the
|
||||
sequential test is usually run against an existing installation and the
|
||||
parallel method against a temporary installation, but there are no technical
|
||||
reasons for this.
|
||||
|
||||
To run the regression tests after building but before installation, type
|
||||
|
||||
$ gmake check
|
||||
|
||||
in the top-level directory. (Or you can change to src/test/regress and run
|
||||
the command there.) This will first build several auxiliary files, such as
|
||||
platform-dependent "expected" files and some sample user-defined trigger
|
||||
functions, and then run the test driver script. At the end you should see
|
||||
something like
|
||||
|
||||
======================
|
||||
All 77 tests passed.
|
||||
======================
|
||||
|
||||
or otherwise a note about what tests failed. See the Section called Test
|
||||
Evaluation below for more.
|
||||
|
||||
Note: Because this test method runs a temporary server, it will
|
||||
not work when you are the root user (the server will not start as
|
||||
root). If you already did the build as root, you do not have to
|
||||
start all over. Instead, make the regression test directory
|
||||
writable by some other user, log in as that user, and restart the
|
||||
tests. For example,
|
||||
|
||||
root# chmod -R a+w src/test/regress
|
||||
root# chmod -R a+w contrib/spi
|
||||
root# su - joeuser
|
||||
joeuser$ cd <build top-level directory>
|
||||
joeuser$ gmake check
|
||||
|
||||
(The only possible "security risk" here is that other users might
|
||||
be able to alter the regression test results behind your back. Use
|
||||
common sense when managing user permissions.)
|
||||
|
||||
Alternatively, run the tests after installation.
|
||||
|
||||
Tip: On some systems, the default Bourne-compatible shell
|
||||
(/bin/sh) gets confused when it has to manage too many child
|
||||
processes in parallel. This may cause the parallel test run to
|
||||
lock up or fail. In such cases, specify a different
|
||||
Bourne-compatible shell on the command line, for example:
|
||||
|
||||
$ gmake SHELL=/bin/ksh check
|
||||
|
||||
To run the tests after installation, initialize a data area and start the
|
||||
server, then type
|
||||
|
||||
$ gmake installcheck
|
||||
|
||||
The tests will expect to contact the server at the local host and the
|
||||
default port number, unless directed otherwise by PGHOST and PGPORT
|
||||
environment variables.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Test Evaluation
|
||||
|
||||
Some properly installed and fully functional PostgreSQL installations can
|
||||
"fail" some of these regression tests due to platform-specific artifacts
|
||||
such as varying floating point representation and time zone support. The
|
||||
tests are currently evaluated using a simple diff comparison against the
|
||||
outputs generated on a reference system, so the results are sensitive to
|
||||
small system differences. When a test is reported as "failed", always
|
||||
examine the differences between expected and actual results; you may well
|
||||
find that the differences are not significant. Nonetheless, we still strive
|
||||
to maintain accurate reference files across all supported platforms, so it
|
||||
can be expected that all tests pass.
|
||||
|
||||
The actual outputs of the regression tests are in files in the
|
||||
src/test/regress/results directory. The test script uses diff to compare
|
||||
each output file against the reference outputs stored in the
|
||||
src/test/regress/expected directory. Any differences are saved for your
|
||||
inspection in src/test/regress/regression.diffs. (Or you can run diff
|
||||
yourself, if you prefer.)
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Error message differences
|
||||
|
||||
Some of the regression tests involve intentional invalid input values. Error
|
||||
messages can come from either the PostgreSQL code or from the host platform
|
||||
system routines. In the latter case, the messages may vary between
|
||||
platforms, but should reflect similar information. These differences in
|
||||
messages will result in a "failed" regression test that can be validated by
|
||||
inspection.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Locale differences
|
||||
|
||||
The tests expect to run in plain "C" locale. This should not cause any
|
||||
problems when you run the tests against a temporary installation, since the
|
||||
regression test driver takes care to start the server in C locale. However,
|
||||
if you run the tests against an already-installed server that is using non-C
|
||||
locale settings, you may see differences caused by varying rules for string
|
||||
sort order, formatting of numeric and monetary values, and so forth.
|
||||
|
||||
In some locales the resulting differences are small and easily checked by
|
||||
inspection. However, in a locale that changes the rules for formatting of
|
||||
numeric values (typically by swapping the usage of commas and decimal
|
||||
points), entry of some data values will fail, resulting in extensive
|
||||
differences later in the tests where the missing data values are supposed to
|
||||
be used.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Date and time differences
|
||||
|
||||
Some of the queries in the timestamp test will fail if you run the test on
|
||||
the day of a daylight-savings time changeover, or the day before or after
|
||||
one. These queries assume that the intervals between midnight yesterday,
|
||||
midnight today and midnight tomorrow are exactly twenty-four hours -- which
|
||||
is wrong if daylight-savings time went into or out of effect meanwhile.
|
||||
|
||||
Most of the date and time results are dependent on the time zone
|
||||
environment. The reference files are generated for time zone PST8PDT
|
||||
(Berkeley, California) and there will be apparent failures if the tests are
|
||||
not run with that time zone setting. The regression test driver sets
|
||||
environment variable PGTZ to PST8PDT, which normally ensures proper results.
|
||||
However, your system must provide library support for the PST8PDT time zone,
|
||||
or the time zone-dependent tests will fail. To verify that your machine does
|
||||
have this support, type the following:
|
||||
|
||||
$ env TZ=PST8PDT date
|
||||
|
||||
The command above should have returned the current system time in the
|
||||
PST8PDT time zone. If the PST8PDT database is not available, then your
|
||||
system may have returned the time in GMT. If the PST8PDT time zone is not
|
||||
available, you can set the time zone rules explicitly:
|
||||
|
||||
PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
|
||||
|
||||
There appear to be some systems that 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.
|
||||
|
||||
Some systems using older time zone libraries fail to apply daylight-savings
|
||||
corrections to dates before 1970, causing pre-1970 PDT times to be displayed
|
||||
in PST instead. This will result in localized differences in the test
|
||||
results.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Floating point differences
|
||||
|
||||
Some of the tests involve computing 64-bit (double precision) numbers from
|
||||
table columns. Differences in results involving mathematical functions of
|
||||
double precision columns have been observed. The float8 and geometry tests
|
||||
are particularly prone to small differences across platforms, or even with
|
||||
different compiler optimization options. 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.
|
||||
|
||||
Some systems signal errors from pow() and exp() differently from the
|
||||
mechanism expected by the current PostgreSQL code.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Polygon differences
|
||||
|
||||
Several of the tests involve operations on geographic data about the
|
||||
Oakland/Berkeley, California street map. The map data is expressed as
|
||||
polygons whose vertices are represented as pairs of double precision numbers
|
||||
(decimal latitude and longitude). Initially, some tables are created and
|
||||
loaded with geographic data, then some views are created that join two
|
||||
tables using the polygon intersection operator (##), then a select is done
|
||||
on the view.
|
||||
|
||||
When comparing the results from different platforms, differences occur in
|
||||
the 2nd or 3rd place to the right of the decimal point. The SQL statements
|
||||
where these problems occur are the following:
|
||||
|
||||
SELECT * from street;
|
||||
SELECT * from iexit;
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
Row ordering differences
|
||||
|
||||
You might see differences in which the same rows are output in a different
|
||||
order than what appears in the expected file. In most cases this is not,
|
||||
strictly speaking, a bug. Most of the regression test scripts are not so
|
||||
pedantic as to use an ORDER BY for every single SELECT, and so their result
|
||||
row orderings are not well-defined according to the letter of the SQL
|
||||
specification. In practice, since we are looking at the same queries being
|
||||
executed on the same data by the same software, we usually get the same
|
||||
result ordering on all platforms, and so the lack of ORDER BY isn't a
|
||||
problem. Some queries do exhibit cross-platform ordering differences,
|
||||
however. (Ordering differences can also be triggered by non-C locale
|
||||
settings.)
|
||||
|
||||
Therefore, if you see an ordering difference, it's not something to worry
|
||||
about, unless the query does have an ORDER BY that your result is violating.
|
||||
But please report it anyway, so that we can add an ORDER BY to that
|
||||
particular query and thereby eliminate the bogus "failure" in future
|
||||
releases.
|
||||
|
||||
You might wonder why we don't order all the regress test queries explicitly
|
||||
to get rid of this issue once and for all. The reason is that that would
|
||||
make the regression tests less useful, not more, since they'd tend to
|
||||
exercise query plan types that produce ordered results to the exclusion of
|
||||
those that don't.
|
||||
|
||||
------------------------------------------------------------------------
|
||||
|
||||
The "random" test
|
||||
|
||||
There is at least one case in the "random" test script that is intended to
|
||||
produce random results. This causes random to fail the regression test once
|
||||
in a while (perhaps once in every five to ten trials). Typing
|
||||
|
||||
diff results/random.out expected/random.out
|
||||
|
||||
should produce only one or a few lines of differences. You need not worry
|
||||
unless the random test always fails in repeated attempts. (On the other
|
||||
hand, if the random test is never reported to fail even in many trials of
|
||||
the regression tests, you probably should worry.)
|
||||
Loading…
Reference in New Issue