mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-21 08:29:39 +08:00
Code Issues Packages Projects Releases Wiki Activity
c82725edfa
postgresql/contrib/pg_upgrade/test.sh

219 lines
5.8 KiB
Bash
Raw Normal View History

Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
#!/bin/sh
# contrib/pg_upgrade/test.sh
#
# Test driver for pg_upgrade. Initializes a new database cluster,
# runs the regression tests (to put in some data), runs pg_dumpall,
# runs pg_upgrade, runs pg_dumpall again, compares the dumps.
#
Update copyright for 2014 Update all files in head, and files COPYRIGHT and legal.sgml in all back branches.
2014-01-08 05:05:30 +08:00
# Portions Copyright (c) 1996-2014, PostgreSQL Global Development Group
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
# Portions Copyright (c) 1994, Regents of the University of California
set -e
: ${MAKE=make}
Make pg_upgrade's test script attempt to select a non-conflicting port. Previously, the port number used in this test script was hard-wired at pg_upgrade's default of 50432; which is not so great because parallel build runs might conflict. Commit 3d53173e20d151341f894f79d556768c845ba3e4 removed this setting for the postmasters started by the script proper (not by pg_upgrade), which didn't do anything to fix that problem and also guaranteed a failure if there was a live postmaster at the build's default port number. Instead, select a non-conflicting temporary port number in the same way that pg_regress.c does. (Its method isn't entirely bulletproof, but given the lack of complaints I'm not going to worry about that today.) In passing, unset MAKEFLAGS and MAKELEVEL to avoid problems with the script's internal invocations of make, for the same reason pg_regress.c does: it could cause problems in a parallel make.
2013-05-12 02:22:18 +08:00
# Guard against parallel make issues (see comments in pg_regress.c)
unset MAKEFLAGS
unset MAKELEVEL
Secure Unix-domain sockets of "make check" temporary clusters. Any OS user able to access the socket can connect as the bootstrap superuser and proceed to execute arbitrary code as the OS user running the test. Protect against that by placing the socket in a temporary, mode-0700 subdirectory of /tmp. The pg_regress-based test suites and the pg_upgrade test suite were vulnerable; the $(prove_check)-based test suites were already secure. Back-patch to 8.4 (all supported versions). The hazard remains wherever the temporary cluster accepts TCP connections, notably on Windows. As a convenient side effect, this lets testing proceed smoothly in builds that override DEFAULT_PGSOCKET_DIR. Popular non-default values like /var/run/postgresql are often unwritable to the build user. Security: CVE-2014-0067
2014-06-14 21:41:13 +08:00
# Establish how the server will listen for connections
Use a more portable platform test.
2012-10-19 04:14:11 +08:00
testhost=`uname -s`
Allow pg_upgrade "make check" to run on Windows/MSys. Backpatch to 9.2.
2012-09-04 10:32:17 +08:00
Prevent creation of postmaster's TCP socket during pg_upgrade testing. On non-Windows machines, we use the Unix socket for connections to test postmasters, so there is no need to create a TCP socket. Furthermore, doing so causes failures due to port conflicts if two builds are carried out concurrently on one machine. (If the builds are done in different chroots, which is standard practice at least in Red Hat distros, there is no risk of conflict on the Unix socket.) Suppressing the TCP socket by setting listen_addresses to empty has long been standard practice for pg_regress, and pg_upgrade knows about this too ... but pg_upgrade's test.sh didn't get the memo. Back-patch to 9.2, and also sync the 9.2 version of the script with HEAD as much as practical.
2013-01-04 07:34:51 +08:00
case $testhost in
Secure Unix-domain sockets of "make check" temporary clusters. Any OS user able to access the socket can connect as the bootstrap superuser and proceed to execute arbitrary code as the OS user running the test. Protect against that by placing the socket in a temporary, mode-0700 subdirectory of /tmp. The pg_regress-based test suites and the pg_upgrade test suite were vulnerable; the $(prove_check)-based test suites were already secure. Back-patch to 8.4 (all supported versions). The hazard remains wherever the temporary cluster accepts TCP connections, notably on Windows. As a convenient side effect, this lets testing proceed smoothly in builds that override DEFAULT_PGSOCKET_DIR. Popular non-default values like /var/run/postgresql are often unwritable to the build user. Security: CVE-2014-0067
2014-06-14 21:41:13 +08:00
MINGW*)
LISTEN_ADDRESSES="localhost"
PGHOST=""; unset PGHOST
;;
*)
LISTEN_ADDRESSES=""
# Select a socket directory. The algorithm is from the "configure"
# script; the outcome mimics pg_regress.c:make_temp_sockdir().
PGHOST=$PG_REGRESS_SOCK_DIR
if [ "x$PGHOST" = x ]; then
{
dir=`(umask 077 &&
mktemp -d /tmp/pg_upgrade_check-XXXXXX) 2>/dev/null` &&
[ -d "$dir" ]
} ||
{
dir=/tmp/pg_upgrade_check-$$-$RANDOM
(umask 077 && mkdir "$dir")
} ||
{
echo "could not create socket temporary directory in \"/tmp\""
exit 1
}
PGHOST=$dir
trap 'rm -rf "$PGHOST"' 0
trap 'exit 3' 1 2 13 15
fi
export PGHOST
;;
Prevent creation of postmaster's TCP socket during pg_upgrade testing. On non-Windows machines, we use the Unix socket for connections to test postmasters, so there is no need to create a TCP socket. Furthermore, doing so causes failures due to port conflicts if two builds are carried out concurrently on one machine. (If the builds are done in different chroots, which is standard practice at least in Red Hat distros, there is no risk of conflict on the Unix socket.) Suppressing the TCP socket by setting listen_addresses to empty has long been standard practice for pg_regress, and pg_upgrade knows about this too ... but pg_upgrade's test.sh didn't get the memo. Back-patch to 9.2, and also sync the 9.2 version of the script with HEAD as much as practical.
2013-01-04 07:34:51 +08:00
esac
Secure Unix-domain sockets of "make check" temporary clusters. Any OS user able to access the socket can connect as the bootstrap superuser and proceed to execute arbitrary code as the OS user running the test. Protect against that by placing the socket in a temporary, mode-0700 subdirectory of /tmp. The pg_regress-based test suites and the pg_upgrade test suite were vulnerable; the $(prove_check)-based test suites were already secure. Back-patch to 8.4 (all supported versions). The hazard remains wherever the temporary cluster accepts TCP connections, notably on Windows. As a convenient side effect, this lets testing proceed smoothly in builds that override DEFAULT_PGSOCKET_DIR. Popular non-default values like /var/run/postgresql are often unwritable to the build user. Security: CVE-2014-0067
2014-06-14 21:41:13 +08:00
POSTMASTER_OPTS="-F -c listen_addresses=$LISTEN_ADDRESSES -k \"$PGHOST\""
Revert "Secure Unix-domain sockets of "make check" temporary clusters." About half of the buildfarm members use too-long directory names, strongly suggesting that this approach is a dead end.
2014-03-29 15:12:00 +08:00
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
temp_root=$PWD/tmp_check
if [ "$1" = '--install' ]; then
temp_install=$temp_root/install
bindir=$temp_install/$bindir
libdir=$temp_install/$libdir
"$MAKE" -s -C ../.. install DESTDIR="$temp_install"
"$MAKE" -s -C ../pg_upgrade_support install DESTDIR="$temp_install"
"$MAKE" -s -C . install DESTDIR="$temp_install"
# platform-specific magic to find the shared libraries; see pg_regress.c
LD_LIBRARY_PATH=$libdir:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
DYLD_LIBRARY_PATH=$libdir:$DYLD_LIBRARY_PATH
export DYLD_LIBRARY_PATH
LIBPATH=$libdir:$LIBPATH
export LIBPATH
PATH=$libdir:$PATH
# We need to make it use psql from our temporary installation,
# because otherwise the installcheck run below would try to
# use psql from the proper installation directory, which might
Extend and improve use of EXTRA_REGRESS_OPTS. This is now used by ecpg tests, and not clobbered by pg_upgrade tests. This change won't affect anything that doesn't set this environment variable, but will enable the buildfarm to control exactly what port regression test installs will be running on, and thus to detect possible rogue postmasters more easily. Backpatch to release 9.2 where EXTRA_REGRESS_OPTS was first used.
2013-01-12 21:28:58 +08:00
# be outdated or missing. But don't override anything else that's
# already in EXTRA_REGRESS_OPTS.
EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --psqldir=$bindir"
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
export EXTRA_REGRESS_OPTS
fi
: ${oldbindir=$bindir}
: ${oldsrc=../..}
oldsrc=`cd "$oldsrc" && pwd`
newsrc=`cd ../.. && pwd`
PATH=$bindir:$PATH
export PATH
Avoid moving data directory in upgrade testing. Windows sometimes gets upset if we rename a large directory and then try to use the old name quickly, as seen in occasional buildfarm failures. So we avoid that by building the old version in the intended destination in the first place instead of renaming it, similar to the change made for the same reason in commit b7f8465c.
2013-03-31 00:44:29 +08:00
BASE_PGDATA=$temp_root/data
PGDATA="$BASE_PGDATA.old"
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
export PGDATA
Avoid moving data directory in upgrade testing. Windows sometimes gets upset if we rename a large directory and then try to use the old name quickly, as seen in occasional buildfarm failures. So we avoid that by building the old version in the intended destination in the first place instead of renaming it, similar to the change made for the same reason in commit b7f8465c.
2013-03-31 00:44:29 +08:00
rm -rf "$BASE_PGDATA" "$PGDATA"
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
Make pg_upgrade's test script attempt to select a non-conflicting port. Previously, the port number used in this test script was hard-wired at pg_upgrade's default of 50432; which is not so great because parallel build runs might conflict. Commit 3d53173e20d151341f894f79d556768c845ba3e4 removed this setting for the postmasters started by the script proper (not by pg_upgrade), which didn't do anything to fix that problem and also guaranteed a failure if there was a live postmaster at the build's default port number. Instead, select a non-conflicting temporary port number in the same way that pg_regress.c does. (Its method isn't entirely bulletproof, but given the lack of complaints I'm not going to worry about that today.) In passing, unset MAKEFLAGS and MAKELEVEL to avoid problems with the script's internal invocations of make, for the same reason pg_regress.c does: it could cause problems in a parallel make.
2013-05-12 02:22:18 +08:00
logdir=$PWD/log
rm -rf "$logdir"
mkdir "$logdir"
# Clear out any environment vars that might cause libpq to connect to
# the wrong postmaster (cf pg_regress.c)
Work around NetBSD shell issue in pg_upgrade test script. The NetBSD shell apparently returns non-zero from an unset command if the variable is already unset. This matters when, as in pg_upgrade's test.sh, we are working under 'set -e'. To protect against this, we first set the PG variables to an empty string before unsetting them completely. Error found on buildfarm member coypu, solution from Rémi Zara.
2013-10-28 23:45:50 +08:00
#
# Some shells, such as NetBSD's, return non-zero from unset if the variable
# is already unset. Since we are operating under 'set -e', this causes the
# script to fail. To guard against this, set them all to an empty string first.
PGDATABASE=""; unset PGDATABASE
PGUSER=""; unset PGUSER
PGSERVICE=""; unset PGSERVICE
Fix unportable shell-script syntax in pg_upgrade's test.sh. I discovered the hard way that on some old shells, the locution FOO="" unset FOO does not behave the same as FOO=""; unset FOO and in fact leaves FOO set to an empty string. test.sh was inconsistently spelling it different ways on adjacent lines. This got broken relatively recently, in commit c737a2e56, so the lack of field reports to date doesn't represent a lot of evidence that the problem is rare.
2014-03-17 09:55:02 +08:00
PGSSLMODE=""; unset PGSSLMODE
Work around NetBSD shell issue in pg_upgrade test script. The NetBSD shell apparently returns non-zero from an unset command if the variable is already unset. This matters when, as in pg_upgrade's test.sh, we are working under 'set -e'. To protect against this, we first set the PG variables to an empty string before unsetting them completely. Error found on buildfarm member coypu, solution from Rémi Zara.
2013-10-28 23:45:50 +08:00
PGREQUIRESSL=""; unset PGREQUIRESSL
PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
PGHOSTADDR=""; unset PGHOSTADDR
Clean environment for pg_upgrade test. This removes exisiting PG settings from the environment for pg_upgrade tests, just like pg_regress does.
2012-11-30 20:54:24 +08:00
Revert "Secure Unix-domain sockets of "make check" temporary clusters." About half of the buildfarm members use too-long directory names, strongly suggesting that this approach is a dead end.
2014-03-29 15:12:00 +08:00
# Select a non-conflicting port number, similarly to pg_regress.c
Make pg_upgrade's test script attempt to select a non-conflicting port. Previously, the port number used in this test script was hard-wired at pg_upgrade's default of 50432; which is not so great because parallel build runs might conflict. Commit 3d53173e20d151341f894f79d556768c845ba3e4 removed this setting for the postmasters started by the script proper (not by pg_upgrade), which didn't do anything to fix that problem and also guaranteed a failure if there was a live postmaster at the build's default port number. Instead, select a non-conflicting temporary port number in the same way that pg_regress.c does. (Its method isn't entirely bulletproof, but given the lack of complaints I'm not going to worry about that today.) In passing, unset MAKEFLAGS and MAKELEVEL to avoid problems with the script's internal invocations of make, for the same reason pg_regress.c does: it could cause problems in a parallel make.
2013-05-12 02:22:18 +08:00
PG_VERSION_NUM=`grep '#define PG_VERSION_NUM' $newsrc/src/include/pg_config.h | awk '{print $3}'`
PGPORT=`expr $PG_VERSION_NUM % 16384 + 49152`
export PGPORT
i=0
while psql -X postgres </dev/null 2>/dev/null
do
i=`expr $i + 1`
if [ $i -eq 16 ]
then
echo port $PGPORT apparently in use
exit 1
fi
PGPORT=`expr $PGPORT + 1`
export PGPORT
done
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
Fix buildfarm incompatibility in updated pg_upgrade test script. Looks like some versions of the buildfarm script try to set the port via --port in $EXTRA_REGRESS_OPTS. Override that ...
2013-05-12 04:14:19 +08:00
# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
export EXTRA_REGRESS_OPTS
Restore set -x in pg_upgrade/test.sh, so the user can see what is being executed.
2012-12-04 12:44:18 +08:00
# enable echo so the user can see what is being executed
set -x
pg_upgrade test: Disable fsync in initdb and postgres calls This mirrors the behavior of pg_regress and makes the test run much faster.
2012-09-27 10:38:15 +08:00
$oldbindir/initdb -N
Prevent creation of postmaster's TCP socket during pg_upgrade testing. On non-Windows machines, we use the Unix socket for connections to test postmasters, so there is no need to create a TCP socket. Furthermore, doing so causes failures due to port conflicts if two builds are carried out concurrently on one machine. (If the builds are done in different chroots, which is standard practice at least in Red Hat distros, there is no risk of conflict on the Unix socket.) Suppressing the TCP socket by setting listen_addresses to empty has long been standard practice for pg_regress, and pg_upgrade knows about this too ... but pg_upgrade's test.sh didn't get the memo. Back-patch to 9.2, and also sync the 9.2 version of the script with HEAD as much as practical.
2013-01-04 07:34:51 +08:00
$oldbindir/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
if "$MAKE" -C "$oldsrc" installcheck; then
Fix pg_upgrade test script's line end handling on Windows. Call pg_dumpall using -f switch instead of redirection, to avoid writing the output in text mode and generating spurious carriage returns. Remove to carriage return ignoring hack introduced by commit e442b0f0c6fd26738bafdeb5222511b586dfe4b9. Backpatch to 9.2.
2012-09-06 06:00:31 +08:00
pg_dumpall -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
if [ "$newsrc" != "$oldsrc" ]; then
oldpgversion=`psql -A -t -d regression -c "SHOW server_version_num"`
fix_sql=""
case $oldpgversion in
804??)
fix_sql="UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%'; DROP FUNCTION public.myfunc(integer);"
;;
900??)
fix_sql="SET bytea_output TO escape; UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%';"
;;
901??)
fix_sql="UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';"
;;
esac
psql -d regression -c "$fix_sql;" || psql_fix_sql_status=$?
mv "$temp_root"/dump1.sql "$temp_root"/dump1.sql.orig
sed "s;$oldsrc;$newsrc;g" "$temp_root"/dump1.sql.orig >"$temp_root"/dump1.sql
fi
else
make_installcheck_status=$?
fi
$oldbindir/pg_ctl -m fast stop
if [ -n "$make_installcheck_status" ]; then
exit 1
fi
if [ -n "$psql_fix_sql_status" ]; then
exit 1
fi
if [ -n "$pg_dumpall1_status" ]; then
echo "pg_dumpall of pre-upgrade database cluster failed"
exit 1
fi
Avoid moving data directory in upgrade testing. Windows sometimes gets upset if we rename a large directory and then try to use the old name quickly, as seen in occasional buildfarm failures. So we avoid that by building the old version in the intended destination in the first place instead of renaming it, similar to the change made for the same reason in commit b7f8465c.
2013-03-31 00:44:29 +08:00
PGDATA=$BASE_PGDATA
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
pg_upgrade test: Disable fsync in initdb and postgres calls This mirrors the behavior of pg_regress and makes the test run much faster.
2012-09-27 10:38:15 +08:00
initdb -N
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
pg_upgrade: more Windows parallel/-j fixes More fixes to handle Windows thread parameter passing. Backpatch to 9.3 beta. Patch originally from Andrew Dunstan
2013-07-25 01:15:47 +08:00
pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "${PGDATA}" -b "$oldbindir" -B "$bindir" -p "$PGPORT" -P "$PGPORT"
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
Prevent creation of postmaster's TCP socket during pg_upgrade testing. On non-Windows machines, we use the Unix socket for connections to test postmasters, so there is no need to create a TCP socket. Furthermore, doing so causes failures due to port conflicts if two builds are carried out concurrently on one machine. (If the builds are done in different chroots, which is standard practice at least in Red Hat distros, there is no risk of conflict on the Unix socket.) Suppressing the TCP socket by setting listen_addresses to empty has long been standard practice for pg_regress, and pg_upgrade knows about this too ... but pg_upgrade's test.sh didn't get the memo. Back-patch to 9.2, and also sync the 9.2 version of the script with HEAD as much as practical.
2013-01-04 07:34:51 +08:00
pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
Allow pg_upgrade "make check" to run on Windows/MSys. Backpatch to 9.2.
2012-09-04 10:32:17 +08:00
Use a more portable platform test.
2012-10-19 04:14:11 +08:00
case $testhost in
MINGW*) cmd /c analyze_new_cluster.bat ;;
*) sh ./analyze_new_cluster.sh ;;
esac
Fix pg_upgrade test script's line end handling on Windows. Call pg_dumpall using -f switch instead of redirection, to avoid writing the output in text mode and generating spurious carriage returns. Remove to carriage return ignoring hack introduced by commit e442b0f0c6fd26738bafdeb5222511b586dfe4b9. Backpatch to 9.2.
2012-09-06 06:00:31 +08:00
pg_dumpall -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
pg_ctl -m fast stop
In pg_upgrade testing script, turn off command echo at the end so status report is clearer.
2012-12-04 21:17:45 +08:00
# no need to echo commands anymore
set +x
echo
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
if [ -n "$pg_dumpall2_status" ]; then
echo "pg_dumpall of post-upgrade database cluster failed"
exit 1
fi
Use a more portable platform test.
2012-10-19 04:14:11 +08:00
case $testhost in
MINGW*) cmd /c delete_old_cluster.bat ;;
*) sh ./delete_old_cluster.sh ;;
esac
Allow pg_upgrade "make check" to run on Windows/MSys. Backpatch to 9.2.
2012-09-04 10:32:17 +08:00
Add pg_upgrade test suite It runs the regression tests, runs pg_upgrade on the populated database, and compares the before and after dumps. While not actually a cross-version upgrade, this does detect omissions and bugs in the involved tools from time to time. It's also possible to do a cross-version upgrade by manually supplying parameters.
2011-11-28 04:42:32 +08:00
if diff -q "$temp_root"/dump1.sql "$temp_root"/dump2.sql; then
echo PASSED
exit 0
else
echo "dumps were not identical"
exit 1
fi
Reference in New Issue Copy Permalink