90 lines
3.3 KiB
Plaintext
90 lines
3.3 KiB
Plaintext
THE SHORT VERSION
|
|
-----------------
|
|
|
|
On non-Windows machines, you can execute the testing process
|
|
described below by running
|
|
make check
|
|
in this directory. This will run the shell script test.sh, performing
|
|
an upgrade from the version in this source tree to a new instance of
|
|
the same version.
|
|
|
|
To test an upgrade from a different version, you must have a built
|
|
source tree for the old version as well as this version, and you
|
|
must have done "make install" for both versions. Then do:
|
|
|
|
export oldsrc=...somewhere/postgresql (old version's source tree)
|
|
export oldbindir=...otherversion/bin (old version's installed bin dir)
|
|
export bindir=...thisversion/bin (this version's installed bin dir)
|
|
export libdir=...thisversion/lib (this version's installed lib dir)
|
|
sh test.sh
|
|
|
|
In this case, you will have to manually eyeball the resulting dump
|
|
diff for version-specific differences, as explained below.
|
|
|
|
|
|
DETAILS
|
|
-------
|
|
|
|
The most effective way to test pg_upgrade, aside from testing on user
|
|
data, is by upgrading the PostgreSQL regression database.
|
|
|
|
This testing process first requires the creation of a valid regression
|
|
database dump. Such files contain most database features and are
|
|
specific to each major version of Postgres.
|
|
|
|
Here are the steps needed to create a regression database dump file:
|
|
|
|
1) Create and populate the regression database in the old cluster.
|
|
This database can be created by running 'make installcheck' from
|
|
src/test/regression.
|
|
|
|
2) Use pg_dump to dump out the regression database. Use the new
|
|
cluster's pg_dump on the old database to minimize whitespace
|
|
differences in the diff.
|
|
|
|
3) Adjust the regression database dump file
|
|
|
|
a) Perform the load/dump twice
|
|
This fixes problems with the ordering of COPY columns for
|
|
inherited tables.
|
|
|
|
b) Change CREATE FUNCTION shared object paths to use '$libdir'
|
|
The old and new cluster will have different shared object paths.
|
|
|
|
c) Fix any wrapping format differences
|
|
Commands like CREATE TRIGGER and ALTER TABLE sometimes have
|
|
differences.
|
|
|
|
d) For pre-9.0, change CREATE OR REPLACE LANGUAGE to CREATE LANGUAGE
|
|
|
|
e) For pre-9.0, remove 'regex_flavor'
|
|
|
|
f) For pre-9.0, adjust extra_float_digits
|
|
Postgres 9.0 pg_dump uses extra_float_digits=-2 for pre-9.0
|
|
databases, and extra_float_digits=-3 for >= 9.0 databases.
|
|
It is necessary to modify 9.0 pg_dump to always use -3, and
|
|
modify the pre-9.0 old server to accept extra_float_digits=-3.
|
|
|
|
Once the dump is created, it can be repeatedly loaded into the old
|
|
database, upgraded, and dumped out of the new database, and then
|
|
compared to the original version. To test the dump file, perform these
|
|
steps:
|
|
|
|
1) Create the old and new clusters in different directories.
|
|
|
|
2) Copy the regression shared object files into the appropriate /lib
|
|
directory for old and new clusters.
|
|
|
|
3) Create the regression database in the old server.
|
|
|
|
4) Load the dump file created above into the regression database;
|
|
check for errors while loading.
|
|
|
|
5) Upgrade the old database to the new major version, as outlined in
|
|
the pg_upgrade manual section.
|
|
|
|
6) Use pg_dump to dump out the regression database in the new cluster.
|
|
|
|
7) Diff the regression database dump file with the regression dump
|
|
file loaded into the old server.
|