summaryrefslogtreecommitdiffstats
path: root/src/bin/pg_upgrade/TESTING
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-16 19:46:48 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-16 19:46:48 +0000
commit311bcfc6b3acdd6fd152798c7f287ddf74fa2a98 (patch)
tree0ec307299b1dada3701e42f4ca6eda57d708261e /src/bin/pg_upgrade/TESTING
parentInitial commit. (diff)
downloadpostgresql-15-311bcfc6b3acdd6fd152798c7f287ddf74fa2a98.tar.xz
postgresql-15-311bcfc6b3acdd6fd152798c7f287ddf74fa2a98.zip
Adding upstream version 15.4.upstream/15.4upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'src/bin/pg_upgrade/TESTING')
-rw-r--r--src/bin/pg_upgrade/TESTING57
1 files changed, 57 insertions, 0 deletions
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
new file mode 100644
index 0000000..564b1ec
--- /dev/null
+++ b/src/bin/pg_upgrade/TESTING
@@ -0,0 +1,57 @@
+THE SHORT VERSION
+-----------------
+
+On non-Windows machines, you can execute the testing process
+described below by running the following command in this directory:
+
+ make check
+
+This will run the TAP tests to run pg_upgrade, performing an upgrade
+from the version in this source tree to a new instance of the same
+version.
+
+Testing an upgrade from a different PG version is also possible, and
+provides a more thorough test that pg_upgrade does what it's meant for.
+This requires both a source tree and an installed tree for the old
+version, as well as a dump file to set up the instance to be upgraded.
+The following environment variables must be set to enable this testing:
+export olddump=...somewhere/dump.sql (old version's dump)
+export oldinstall=...otherversion/ (old version's install base path)
+See DETAILS below for more information about creation of the dump.
+
+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 that can then be used for $olddump. Such files contain
+most database features and are specific to each major version of Postgres.
+
+Here are the steps needed to create a 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/regress in the old version's source code tree.
+
+ If you like, you can also populate regression databases for one or
+ more contrib modules by running 'make installcheck USE_MODULE_DB=1'
+ in their directories. (USE_MODULE_DB is essential so that the
+ pg_upgrade test script will understand which database is which.)
+
+2) Use pg_dumpall to dump out the contents of the instance, including the
+ regression database(s), into a SQL file. Use the *old* version's
+ pg_dumpall so that the dump created is compatible with that version.
+
+Once the dump file is created, it can be used repeatedly. Set $olddump
+to point to the dump file and run 'make check' or 'make installcheck'
+in the new version's src/bin/pg_upgrade directory. (If you included any
+contrib databases in the old dump, you must use 'make installcheck' and
+ensure that the corresponding contrib modules have been installed in
+the new version's installation tree.) This will build a temporary cluster
+using the old installation's executables, populate it from the dump file,
+and then try to pg_upgrade it to the new version. Success is reported
+if pg_dumpall output matches between the pre-upgrade and post-upgrade
+databases. In case of trouble, manually comparing those dump files may
+help to isolate the problem.