database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-07 00:36:50 +03:00
Code Activity

Update to current information for upcoming v6.1 production release.

Browse Source
This commit is contained in:
Thomas G. Lockhart
1997-05-11 15:46:19 +00:00
parent cc25efef92
commit 8ce8d6550f
2 changed files with 31 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
src/test/regress/README
View File

@ -84,16 +84,15 @@ OID differences
The 'a,523676' row is composed from an OID. The 'a,523676' row is composed from an OID.
TIME differences DATE/TIME differences
Some of the tests involving date/time functions use the implicit On many supported platforms, you can force PostgreSQL to believe that it
time zone in effect at the time the regression test is run. In other is running in the same time zone as Berkeley, California. See details in
tests the timezone to be inserted into the regression data base is the section on how to run the regression tests.
explicitly specified.
The 'expected.input' file was prepared in the 'US/Pacific' timezone If you do not explicitly set your time zone environment to PST/PDT, then
so there may be differences where the 'expected.out' file has most of the date and time results will reflect your local time zone and
PST/PDT times and the 'regress.out' file has your local timezone. will fail the regression testing.
FLOATING POINT differences FLOATING POINT differences
@ -125,26 +124,14 @@ POLYGON differences
QUERY: SELECT * from street; QUERY: SELECT * from street;
QUERY: SELECT * from iexit; QUERY: SELECT * from iexit;
DATE/TIME differences
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.
The Makefile attempts to adjust for timezone differences, but it is
not possible to totally eliminate them. People outside North America
will probabablly find the Makefile's adjustments are incorrect. Also
entries that use the time -infinity display with year 1970 plus/minus the
number of hours you are different from GMT.
Random differences Random differences
There is at least one test case in misc.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 misc to fail the regression testing. random results. This causes random to fail the regression testing.
Typing "diff results/misc.out expected/misc.out" should produce only Typing "diff results/random.out expected/random.out" should produce only
one or a few lines of differences for this reason, but other floating one or a few lines of differences for this reason, but other floating
point differences on dissimilar architectures might cause many more point differences on dissimilar architectures might cause many more
differences. differences. See the release notes below.
The 'expected' files The 'expected' files
@ -165,11 +152,7 @@ The 'expected' files
have been created on a DEC ALPHA machine as the 'Makefile.global' have been created on a DEC ALPHA machine as the 'Makefile.global'
in the postgres-1.01 release has PORTNAME=alpha. in the postgres-1.01 release has PORTNAME=alpha.
Current release notes Current release notes (Thomas.Lockhart@jpl.nasa.gov)
There are no release notes for PostgreSQL v6.0.
v6.1beta release notes
The regression tests have been adapted and extensively modified for the The regression tests have been adapted and extensively modified for the
v6.1 release of PostgreSQL. v6.1 release of PostgreSQL.
@ -182,29 +165,25 @@ v6.1beta release notes
misc.out has only been spot-checked for correctness relative to the misc.out has only been spot-checked for correctness relative to the
original regression output. original regression output.
To get consistant results from the regression tests, compile the PostgreSQL PostgreSQL v6.1 introduces a new, alternate optimizer which uses "genetic"
backend with the genetic optimizer (GEQ) turned off. The genetic algorithms algorithms. These algorithms introduce a random behavior in the ordering
introduce a random behavior in the output ordering which causes the of query results when the query contains multiple qualifiers or multiple
simple "diff" implementation of the tests to fail. To turn off the genetic tables (giving the optimizer a choice on order of evaluation). Several
optimizer, edit the src/include/config.h file and comment-out the line regression tests have been modified to explicitly order the results, and
containing "#define GEQ", then do a "make clean install" to regenerate hence are insensitive to optimizer choices. A few regression tests are
the backend. Existing v6.1 databases are not affected by the choice of for data types which are inherently unordered (e.g. points and time
optimizer, so there is no need to reload after changing the optimizer. intervals) and tests involving those types are explicitly bracketed with
The new genetic optimizer has very nice performance with many-table joins, "set geqo to 'off'" and "reset geqo".
so you may want to make sure to re-enable it and reinstall the code after
you have concluded your regression testing.
XXX update this for the production release - tgl 97/04/26
The interpretation of array specifiers (the curly braces around atomic The interpretation of array specifiers (the curly braces around atomic
values) appears to have changed sometime after the original regression values) appears to have changed sometime after the original regression
tests were generated. The current ./expected/*.out files reflect this tests were generated. The current ./expected/*.out files reflect this
new interpretation, which may not be correct! new interpretation, which may not be correct!
XXX update this for the production release - tgl 97/04/26 The float8 regression test fails on at least some platforms. This is due
The float8 regression test fails. This may be due to the parser continuing to differences in implementations of pow() and exp() and the signaling
rather than aborting when given invalid constants for input values. mechanisms used for overflow and underflow conditions.
XXX update this for the production release - tgl 97/04/26 The "random" results in the random test do not seem to produce random
Regression tests involving indexed tables fail in at least some environments. results on my test machine (Linux/gcc/i686).
This may indicate a problem with the current index code.

10
src/test/regress/regress.sh
View File

@ -1,5 +1,5 @@
#!/bin/sh #!/bin/sh
# $Header: /cvsroot/pgsql/src/test/regress/Attic/regress.sh,v 1.9 1997/04/27 18:55:37 scrappy Exp $ # $Header: /cvsroot/pgsql/src/test/regress/Attic/regress.sh,v 1.10 1997/05/11 15:46:19 thomas Exp $
# #
if echo '\c' | grep -s c >/dev/null 2>&1 if echo '\c' | grep -s c >/dev/null 2>&1
then then
@ -21,12 +21,10 @@ FRONTEND="psql -n -e -q"
echo "=============== Notes... =================" echo "=============== Notes... ================="
echo "postmaster must already be running for the regression tests to succeed." echo "postmaster must already be running for the regression tests to succeed."
echo "The non-GEQ optimizer will give more consistant results than will the" echo "The time zone must be set to PST/PDT for the date and time data types"
echo " GEQ optimizer. See the regression testing README for more details." echo " to pass the regression tests; to do this type"
echo "The time zone might need to be set to PST/PDT for the date and time data"
echo " types to pass the regression tests; to do this type"
echo " setenv TZ $TZ" echo " setenv TZ $TZ"
echo " before starting the postmaster." echo " before starting postmaster."
echo "" echo ""
echo "=============== destroying old regression database... =================" echo "=============== destroying old regression database... ================="