($INBOX_DIR/description missing)
help / color / mirror / Atom feedRewriting the test of pg_upgrade as a TAP test
118+ messages / 17 participants
[nested] [flat]
* Rewriting the test of pg_upgrade as a TAP test
@ 2017-04-03 13:07 Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
0 siblings, 2 replies; 118+ messages in thread
From: Michael Paquier @ 2017-04-03 13:07 UTC (permalink / raw)
To: pgsql-hackers; +Cc: Noah Misch <[email protected]>
Hi all,
The $subject has been mentioned a couple of times already, the last
one being here:
https://www.postgresql.org/message-id/[email protected]
The code tree has to maintain now two set of scripts for the same
test: test.sh for all *nix platforms, and vcregress.pl for MSVC.
Attached is a patch to remove that and replace the existing test by a
TAP test. The size of the patch speaks by itself:
6 files changed, 98 insertions(+), 389 deletions(-)
I had for some time a WIP patch on which dust has accumulated, so
attached is a more polished version. In more details, here is what
happens:
- test.sh is removed.
- vcregress.pl loses upgradecheck.
- The new test is added. In the case of MSVC this is now part of bincheck.
Patch has been tested on macos and Windows.
I am parking that in the next commit fest.
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] pgupgrade-tap-test.patch (17.8K, ../../CAB7nPqRdaN1A1YNjxNL9T1jUEWct8ttqq29dNv8W_o37+e8wfA@mail.gmail.com/2-pgupgrade-tap-test.patch)
download | inline diff:
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index ecec0a60c7..b7651c5b33 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -452,7 +452,6 @@ $ENV{CONFIG}="Debug";
<userinput>vcregress isolationcheck</userinput>
<userinput>vcregress bincheck</userinput>
<userinput>vcregress recoverycheck</userinput>
-<userinput>vcregress upgradecheck</userinput>
</screen>
To change the schedule used (default is parallel), append it to the
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 8823288708..a78b39f3e5 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -35,9 +35,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-check: test.sh all
- MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $< --install
+check:
+ $(prove_check)
-# disabled because it upsets the build farm
-#installcheck: test.sh
-# MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) $(SHELL) $<
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
index 4ecfc5798e..4885164d04 100644
--- a/src/bin/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -61,7 +61,7 @@ steps:
7) Diff the regression database dump file with the regression dump
file loaded into the old server.
-The shell script test.sh in this directory performs more or less this
+The TAP test scripts in this directory perform more or less this
procedure. You can invoke it by running
make check
@@ -69,13 +69,3 @@ procedure. You can invoke it by running
or by running
make installcheck
-
-if "make install" (or "make install-world") were done beforehand.
-When invoked without arguments, it will run 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, invoke it like this:
-
- make installcheck oldbindir=...otherversion/bin oldsrc=...somewhere/postgresql
-
-In this case, you will have to manually eyeball the resulting dump
-diff for version-specific differences, as explained above.
diff --git a/src/bin/pg_upgrade/t/010_pg_upgrade.pl b/src/bin/pg_upgrade/t/010_pg_upgrade.pl
new file mode 100644
index 0000000000..765bd963bb
--- /dev/null
+++ b/src/bin/pg_upgrade/t/010_pg_upgrade.pl
@@ -0,0 +1,91 @@
+# Set of tests for pg_upgrade.
+use strict;
+use warnings;
+use Cwd;
+use Config;
+use File::Basename;
+use IPC::Run;
+use PostgresNode;
+use TestLib;
+use Test::More tests => 9;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log([ 'createdb', '--port', $node->port, $dbname ]);
+}
+
+my $startdir = getcwd();
+
+# From now on, the test of pg_upgrade consists in setting up an instance
+# on which regression tests are run. This is the source instance used
+# for the upgrade. Then a new, fresh instance is created, and is used
+# as the target instance for the upgrade. Before running an upgrade a
+# logical dump of the old instance is taken, and a second logical dump
+# of the new instance is taken after the upgrade. The upgrade test
+# passes if there are no differences after running pg_upgrade.
+
+# Temporary location for dumps taken
+my $tempdir = TestLib::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = get_new_node('old_node');
+$oldnode->init;
+$oldnode->start;
+
+# Creating databases with names covering most ASCII bytes
+generate_db($oldnode, 1, 45);
+generate_db($oldnode, 46, 90);
+generate_db($oldnode, 91, 127);
+
+# Run regression tests on the old instance
+chdir dirname($ENV{PG_REGRESS});
+$oldnode->run_log([ 'createdb', '--port', $oldnode->port, 'regression' ]);
+run_log([$ENV{PG_REGRESS}, '--schedule', './serial_schedule',
+ '--dlpath', '.', '--bindir=', '--use-existing',
+ '--port', $oldnode->port]);
+
+# Take a dump before performing the upgrade as a base comparison.
+run_log(['pg_dumpall', '--port', $oldnode->port, '-f', "$tempdir/dump1.sql"]);
+
+# Move back to current directory, all logs generated need to be located
+# at the origin.
+chdir $startdir;
+
+# Update the instance.
+$oldnode->stop;
+
+# pg_upgrade needs the location of the old and new binaries. This test
+# relying on binaries being in PATH, so is pg_config. So fetch from it
+# the real binary location.
+my ($bindir, $stderr);
+my $result = IPC::Run::run [ 'pg_config', '--bindir' ], '>', \$bindir, '2>', \$stderr;
+chomp($bindir);
+
+# Initialize a new node for the upgrade.
+my $newnode = get_new_node('new_node');
+$newnode->init;
+
+# Time for the real run.
+run_log(['pg_upgrade', '-d', $oldnode->data_dir, -D, $newnode->data_dir,
+ '-b', $bindir, '-B', $bindir, '-p', $oldnode->port, '-P', $newnode->port]);
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+run_log(['pg_dumpall', '--port', $newnode->port, '-f', "$tempdir/dump2.sql"]);
+
+# Compare the two dumps, there should be no differences.
+command_ok(['diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql"],
+ 'Old and new dump checks after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index cbc5259550..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,248 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- "$1" -N
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# Establish how the server will listen for connections
-testhost=`uname -s`
-
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PGHOST=localhost
- ;;
- *)
- 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
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=$LISTEN_ADDRESSES -k \"$PGHOST\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-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"
-
- # 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
- SHLIB_PATH=$libdir:$SHLIB_PATH
- export SHLIB_PATH
- 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
- # be outdated or missing. But don't override anything else that's
- # already in EXTRA_REGRESS_OPTS.
- EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$bindir'"
- export EXTRA_REGRESS_OPTS
-fi
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA=$temp_root/data
-PGDATA="$BASE_PGDATA.old"
-export PGDATA
-rm -rf "$BASE_PGDATA" "$PGDATA"
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-# enable echo so the user can see what is being executed
-set -x
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "$dbname1" || createdb_status=$?
-createdb "$dbname2" || createdb_status=$?
-createdb "$dbname3" || createdb_status=$?
-
-if "$MAKE" -C "$oldsrc" installcheck; then
- pg_dumpall -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
- if [ "$newsrc" != "$oldsrc" ]; then
- oldpgversion=`psql -X -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 -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA=$BASE_PGDATA
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "${PGDATA}" -b "$oldbindir" -B "$bindir" -p "$PGPORT" -P "$PGPORT"
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-case $testhost in
- MINGW*) cmd /c analyze_new_cluster.bat ;;
- *) sh ./analyze_new_cluster.sh ;;
-esac
-
-pg_dumpall -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-# no need to echo commands anymore
-set +x
-echo
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 8933920d9b..7d6fb6200a 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -34,7 +34,7 @@ if (-e "src/tools/msvc/buildenv.pl")
my $what = shift || "";
if ($what =~
-/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|upgradecheck|bincheck|recoverycheck)$/i
+/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|bincheck|recoverycheck)$/i
)
{
$what = uc $what;
@@ -89,8 +89,7 @@ my %command = (
MODULESCHECK => \&modulescheck,
ISOLATIONCHECK => \&isolationcheck,
BINCHECK => \&bincheck,
- RECOVERYCHECK => \&recoverycheck,
- UPGRADECHECK => \&upgradecheck,);
+ RECOVERYCHECK => \&recoverycheck,);
my $proc = $command{$what};
@@ -382,126 +381,6 @@ sub standard_initdb
$ENV{PGDATA}) == 0);
}
-# This is similar to appendShellString(). Perl system(@args) bypasses
-# cmd.exe, so omit the caret escape layer.
-sub quote_system_arg
-{
- my $arg = shift;
-
- # Change N >= 0 backslashes before a double quote to 2N+1 backslashes.
- $arg =~ s/(\\*)"/${\($1 . $1)}\\"/gs;
-
- # Change N >= 1 backslashes at end of argument to 2N backslashes.
- $arg =~ s/(\\+)$/${\($1 . $1)}/gs;
-
- # Wrap the whole thing in unescaped double quotes.
- return "\"$arg\"";
-}
-
-# Generate a database with a name made of a range of ASCII characters, useful
-# for testing pg_upgrade.
-sub generate_db
-{
- my ($prefix, $from_char, $to_char, $suffix) = @_;
-
- my $dbname = $prefix;
- for my $i ($from_char .. $to_char)
- {
- next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
- $dbname = $dbname . sprintf('%c', $i);
- }
- $dbname .= $suffix;
-
- system('createdb', quote_system_arg($dbname));
- my $status = $? >> 8;
- exit $status if $status;
-}
-
-sub upgradecheck
-{
- my $status;
- my $cwd = getcwd();
-
- # Much of this comes from the pg_upgrade test.sh script,
- # but it only covers the --install case, and not the case
- # where the old and new source or bin dirs are different.
- # i.e. only this version to this version check. That's
- # what pg_upgrade's "make check" does.
-
- $ENV{PGHOST} = 'localhost';
- $ENV{PGPORT} ||= 50432;
- my $tmp_root = "$topdir/src/bin/pg_upgrade/tmp_check";
- (mkdir $tmp_root || die $!) unless -d $tmp_root;
- my $upg_tmp_install = "$tmp_root/install"; # unshared temp install
- print "Setting up temp install\n\n";
- Install($upg_tmp_install, "all", $config);
-
- # Install does a chdir, so change back after that
- chdir $cwd;
- my ($bindir, $libdir, $oldsrc, $newsrc) =
- ("$upg_tmp_install/bin", "$upg_tmp_install/lib", $topdir, $topdir);
- $ENV{PATH} = "$bindir;$ENV{PATH}";
- my $data = "$tmp_root/data";
- $ENV{PGDATA} = "$data.old";
- my $logdir = "$topdir/src/bin/pg_upgrade/log";
- (mkdir $logdir || die $!) unless -d $logdir;
- print "\nRunning initdb on old cluster\n\n";
- standard_initdb() or exit 1;
- print "\nStarting old cluster\n\n";
- my @args = ('pg_ctl', 'start', '-l', "$logdir/postmaster1.log");
- system(@args) == 0 or exit 1;
-
- print "\nCreating databases with names covering most ASCII bytes\n\n";
- generate_db("\\\"\\", 1, 45, "\\\\\"\\\\\\");
- generate_db('', 46, 90, '');
- generate_db('', 91, 127, '');
-
- print "\nSetting up data for upgrading\n\n";
- installcheck();
-
- # now we can chdir into the source dir
- chdir "$topdir/src/bin/pg_upgrade";
- print "\nDumping old cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump1.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping old cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- $ENV{PGDATA} = "$data";
- print "\nSetting up new cluster\n\n";
- standard_initdb() or exit 1;
- print "\nRunning pg_upgrade\n\n";
- @args = (
- 'pg_upgrade', '-d', "$data.old", '-D', $data, '-b',
- $bindir, '-B', $bindir);
- system(@args) == 0 or exit 1;
- print "\nStarting new cluster\n\n";
- @args = ('pg_ctl', '-l', "$logdir/postmaster2.log", 'start');
- system(@args) == 0 or exit 1;
- print "\nSetting up stats on new cluster\n\n";
- system(".\\analyze_new_cluster.bat") == 0 or exit 1;
- print "\nDumping new cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump2.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping new cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- print "\nDeleting old cluster\n\n";
- system(".\\delete_old_cluster.bat") == 0 or exit 1;
- print "\nComparing old and new cluster dumps\n\n";
-
- @args = ('diff', '-q', "$tmp_root/dump1.sql", "$tmp_root/dump2.sql");
- system(@args);
- $status = $?;
- if (!$status)
- {
- print "PASSED\n";
- }
- else
- {
- print "dumps not identical!\n";
- exit(1);
- }
-}
-
sub fetchRegressOpts
{
my $handle;
@@ -607,7 +486,6 @@ sub usage
" modulescheck run tests of modules in src/test/modules/\n",
" plcheck run tests of PL languages\n",
" recoverycheck run recovery test suite\n",
- " upgradecheck run tests of pg_upgrade\n",
"\nOptions for <schedule>:\n",
" serial serial mode\n",
" parallel parallel mode\n";
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-04-03 13:12 ` Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Craig Ringer @ 2017-04-03 13:12 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: pgsql-hackers; Noah Misch <[email protected]>
On 3 April 2017 at 21:07, Michael Paquier <[email protected]> wrote:
> Hi all,
>
> The $subject has been mentioned a couple of times already, the last
> one being here:
> https://www.postgresql.org/message-id/[email protected]
>
> The code tree has to maintain now two set of scripts for the same
> test: test.sh for all *nix platforms, and vcregress.pl for MSVC.
> Attached is a patch to remove that and replace the existing test by a
> TAP test. The size of the patch speaks by itself:
> 6 files changed, 98 insertions(+), 389 deletions(-)
>
> I had for some time a WIP patch on which dust has accumulated, so
> attached is a more polished version. In more details, here is what
> happens:
> - test.sh is removed.
> - vcregress.pl loses upgradecheck.
> - The new test is added. In the case of MSVC this is now part of bincheck.
> Patch has been tested on macos and Windows.
>
> I am parking that in the next commit fest.
Great.
Count me in as reviewer, and feel free to poke me if I get caught up
in other things.
I'd like to see us adopting TAP for cross-version stuff in pg_dump etc
too, down the track.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
@ 2017-04-03 15:12 ` Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Stephen Frost @ 2017-04-03 15:12 UTC (permalink / raw)
To: Craig Ringer <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Craig, Michael,
* Craig Ringer ([email protected]) wrote:
> On 3 April 2017 at 21:07, Michael Paquier <[email protected]> wrote:
> > I am parking that in the next commit fest.
>
> Great.
>
> Count me in as reviewer, and feel free to poke me if I get caught up
> in other things.
I'm interested in this also.
> I'd like to see us adopting TAP for cross-version stuff in pg_dump etc
> too, down the track.
I'm very curious what you're thinking here? IIRC, Andrew had some ideas
for how to do true cross-version testing with TAP in the buildfarm, but
I don't think we actually have that yet..?
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-03 22:28 ` Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-04-03 22:28 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Craig Ringer <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
On Tue, Apr 4, 2017 at 12:12 AM, Stephen Frost <[email protected]> wrote:
> I'm very curious what you're thinking here? IIRC, Andrew had some ideas
> for how to do true cross-version testing with TAP in the buildfarm, but
> I don't think we actually have that yet..?
I heard about nothing in this area. Cross-branch tests may be an
interesting challenge as tests written in branch X may not be in Y.
The patch presented here does lower the coverage we have now.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-04-03 22:38 ` Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Stephen Frost @ 2017-04-03 22:38 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
Michael,
On Mon, Apr 3, 2017 at 18:29 Michael Paquier <[email protected]>
wrote:
> On Tue, Apr 4, 2017 at 12:12 AM, Stephen Frost <[email protected]> wrote:
> > I'm very curious what you're thinking here? IIRC, Andrew had some ideas
> > for how to do true cross-version testing with TAP in the buildfarm, but
> > I don't think we actually have that yet..?
>
> I heard about nothing in this area. Cross-branch tests may be an
> interesting challenge as tests written in branch X may not be in Y.
> The patch presented here does lower the coverage we have now.
Not good if it lowers the coverage, but hopefully that's fixable. Have you
analyzed where we're reducing coverage..?
As for what I'm remembering, there's this:
https://www.postgresql.org/message-id/[email protected]
Of course, it's possible I misunderstood..
That seems focused on upgrading and I'd really like to see a general way to
do this with the TAP structure, specifically so we can test pg_dump and
psql against older versions. Having the ability to then be run under the
coverage testing would be fantastic and would help a great deal with the
coverage report.
Thanks!
Stephen
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-03 23:51 ` Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-04-03 23:51 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost <[email protected]> wrote:
> Not good if it lowers the coverage, but hopefully that's fixable. Have you
> analyzed where we're reducing coverage..?
The current set of tests is just running pg_upgrade using the same
version for the source and target instances. Based on that I am not
lowering what is happening in this set of tests. Just doing some
cleanup.
> As for what I'm remembering, there's this:
> https://www.postgresql.org/message-id/[email protected]
>
> Of course, it's possible I misunderstood..
This invokes directly pg_upgrade, so that's actually a third,
different way to test pg_upgrade on top of the two existing methods
that are used in vcregress.pl and pg_upgrade's test.sh
> That seems focused on upgrading and I'd really like to see a general way to
> do this with the TAP structure, specifically so we can test pg_dump and psql
> against older versions. Having the ability to then be run under the
> coverage testing would be fantastic and would help a great deal with the
> coverage report.
I don't disagree with that. What we need first is some logic to store
in a temporary directory the installation of all the previous major
versions that we have. For example use a subfolder in tmp_install
tagged with the major version number, and then when the TAP test
starts we scan for all the versions present in tmp_install and test
the upgrade with a full grid. One issue though is that we add
$(bindir) in PATH and that there is currently no logic to change PATH
automatically depending on the major/minor versions you are working
on.
So in short I don't think that this lack of infrastructure should be a
barrier for what is basically a cleanup but... I just work here.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-04-04 12:30 ` Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Stephen Frost @ 2017-04-04 12:30 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
* Michael Paquier ([email protected]) wrote:
> On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost <[email protected]> wrote:
> > Not good if it lowers the coverage, but hopefully that's fixable. Have you
> > analyzed where we're reducing coverage..?
>
> The current set of tests is just running pg_upgrade using the same
> version for the source and target instances. Based on that I am not
> lowering what is happening in this set of tests. Just doing some
> cleanup.
Ok, I'm confused.
I wrote the above in response to your statement:
> The patch presented here does lower the coverage we have now.
I assume (perhaps mistakenly) that this statement was based on an
analysis of before-and-after 'make coverage' runs. Here you are saying
that you're *not* lowering the coverage.
I understand how the current pg_upgrade tests work. I don't see
off-hand why the TAP tests would reduce the code coverage of pg_upgrade,
but if they do, we should be able to figure out why and correct it.
> > As for what I'm remembering, there's this:
> > https://www.postgresql.org/message-id/[email protected]
> >
> > Of course, it's possible I misunderstood..
>
> This invokes directly pg_upgrade, so that's actually a third,
> different way to test pg_upgrade on top of the two existing methods
> that are used in vcregress.pl and pg_upgrade's test.sh
Ok, though I'm not sure that I see that as necessairly a bad thing.
There are only specific tools that we actually worry about being able to
work with older versions of PG, after all.
> > That seems focused on upgrading and I'd really like to see a general way to
> > do this with the TAP structure, specifically so we can test pg_dump and psql
> > against older versions. Having the ability to then be run under the
> > coverage testing would be fantastic and would help a great deal with the
> > coverage report.
>
> I don't disagree with that. What we need first is some logic to store
> in a temporary directory the installation of all the previous major
> versions that we have. For example use a subfolder in tmp_install
> tagged with the major version number, and then when the TAP test
> starts we scan for all the versions present in tmp_install and test
> the upgrade with a full grid. One issue though is that we add
> $(bindir) in PATH and that there is currently no logic to change PATH
> automatically depending on the major/minor versions you are working
> on.
Right, I figured that what Andrew did in the above post was something
along these lines, but I've not looked at it in any depth.
> So in short I don't think that this lack of infrastructure should be a
> barrier for what is basically a cleanup but... I just work here.
I didn't mean to imply that this patch needs to address the
cross-version testing challenge, was merely mentioning that there's been
some work in this area already by Andrew and that if you're interested
in working on that problem that you should probably coordinate with him.
What I do think is a barrier to this patch moving forward is if it
reduces our current code coverage testing (with the same-version
pg_upgrade that's run in the regular regression tests). If it doesn't,
then great, but if it does, then the patch should be updated to fix
that.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-05 02:28 ` Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-04-05 02:28 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
On Tue, Apr 4, 2017 at 9:30 PM, Stephen Frost <[email protected]> wrote:
> * Michael Paquier ([email protected]) wrote:
>> On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost <[email protected]> wrote:
>> The patch presented here does lower the coverage we have now.
>
> I assume (perhaps mistakenly) that this statement was based on an
> analysis of before-and-after 'make coverage' runs. Here you are saying
> that you're *not* lowering the coverage.
My apologies here, when I used the work "coverage" in my previous
emails it visibly implied that I meant that I had used the coverage
stuff. But I did not because the TAP test proposed does exactly what
test.sh is doing:
1) Initialize the old cluster and start it.
2) create a bunch of databases with full range of ascii characters.
3) Run regression tests.
4) Take dump on old cluster.
4) Stop the old cluster.
5) Initialize the new cluster.
6) Run pg_upgrade.
7) Start new cluster.
8) Take dump from it.
9) Run deletion script (Oops forgot this part!)
> I understand how the current pg_upgrade tests work. I don't see
> off-hand why the TAP tests would reduce the code coverage of pg_upgrade,
> but if they do, we should be able to figure out why and correct it.
Good news is that this patch at least does not lower the bar.
>> So in short I don't think that this lack of infrastructure should be a
>> barrier for what is basically a cleanup but... I just work here.
>
> I didn't mean to imply that this patch needs to address the
> cross-version testing challenge, was merely mentioning that there's been
> some work in this area already by Andrew and that if you're interested
> in working on that problem that you should probably coordinate with him.
Sure.
> What I do think is a barrier to this patch moving forward is if it
> reduces our current code coverage testing (with the same-version
> pg_upgrade that's run in the regular regression tests). If it doesn't,
> then great, but if it does, then the patch should be updated to fix
> that.
I did not do a coverage test first, but surely this patch needs
numbers, so here you go.
Without the patch, here is the coverage of src/bin/pg_upgrade:
lines......: 57.7% (1311 of 2273 lines)
functions..: 85.3% (87 of 102 functions)
And with the patch:
lines......: 58.8% (1349 of 2294 lines)
functions..: 85.6% (89 of 104 functions)
The coverage gets a bit higher as a couple of basic code paths like
pg_upgrade --help get looked at.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] pgupgrade-tap-test-v2.patch (18.0K, ../../CAB7nPqToUk6z=+jk11rNiEShoL5963Jwx4jg+svKuKHvZ3hhtQ@mail.gmail.com/2-pgupgrade-tap-test-v2.patch)
download | inline diff:
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index ecec0a60c7..b7651c5b33 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -452,7 +452,6 @@ $ENV{CONFIG}="Debug";
<userinput>vcregress isolationcheck</userinput>
<userinput>vcregress bincheck</userinput>
<userinput>vcregress recoverycheck</userinput>
-<userinput>vcregress upgradecheck</userinput>
</screen>
To change the schedule used (default is parallel), append it to the
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 8823288708..a78b39f3e5 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -35,9 +35,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-check: test.sh all
- MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $< --install
+check:
+ $(prove_check)
-# disabled because it upsets the build farm
-#installcheck: test.sh
-# MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) $(SHELL) $<
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
index 4ecfc5798e..4885164d04 100644
--- a/src/bin/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -61,7 +61,7 @@ steps:
7) Diff the regression database dump file with the regression dump
file loaded into the old server.
-The shell script test.sh in this directory performs more or less this
+The TAP test scripts in this directory perform more or less this
procedure. You can invoke it by running
make check
@@ -69,13 +69,3 @@ procedure. You can invoke it by running
or by running
make installcheck
-
-if "make install" (or "make install-world") were done beforehand.
-When invoked without arguments, it will run 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, invoke it like this:
-
- make installcheck oldbindir=...otherversion/bin oldsrc=...somewhere/postgresql
-
-In this case, you will have to manually eyeball the resulting dump
-diff for version-specific differences, as explained above.
diff --git a/src/bin/pg_upgrade/t/010_pg_upgrade.pl b/src/bin/pg_upgrade/t/010_pg_upgrade.pl
new file mode 100644
index 0000000000..9a956c96b3
--- /dev/null
+++ b/src/bin/pg_upgrade/t/010_pg_upgrade.pl
@@ -0,0 +1,96 @@
+# Set of tests for pg_upgrade.
+use strict;
+use warnings;
+use Cwd;
+use Config;
+use File::Basename;
+use IPC::Run;
+use PostgresNode;
+use TestLib;
+use Test::More tests => 10;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log(['createdb', '--port', $node->port, $dbname]);
+}
+
+my $startdir = getcwd();
+
+# From now on, the test of pg_upgrade consists in setting up an instance
+# on which regression tests are run. This is the source instance used
+# for the upgrade. Then a new, fresh instance is created, and is used
+# as the target instance for the upgrade. Before running an upgrade a
+# logical dump of the old instance is taken, and a second logical dump
+# of the new instance is taken after the upgrade. The upgrade test
+# passes if there are no differences after running pg_upgrade.
+
+# Temporary location for dumps taken
+my $tempdir = TestLib::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = get_new_node('old_node');
+$oldnode->init;
+$oldnode->start;
+
+# Creating databases with names covering most ASCII bytes
+generate_db($oldnode, 1, 45);
+generate_db($oldnode, 46, 90);
+generate_db($oldnode, 91, 127);
+
+# Run regression tests on the old instance
+chdir dirname($ENV{PG_REGRESS});
+$oldnode->run_log(['createdb', '--port', $oldnode->port, 'regression']);
+#run_log([$ENV{PG_REGRESS}, '--schedule', './serial_schedule',
+# '--dlpath', '.', '--bindir=', '--use-existing',
+# '--port', $oldnode->port]);
+
+# Take a dump before performing the upgrade as a base comparison.
+run_log(['pg_dumpall', '--port', $oldnode->port, '-f', "$tempdir/dump1.sql"]);
+
+# Move back to current directory, all logs generated need to be located
+# at the origin.
+chdir $startdir;
+
+# Update the instance.
+$oldnode->stop;
+
+# pg_upgrade needs the location of the old and new binaries. This test
+# relying on binaries being in PATH, so is pg_config. So fetch from it
+# the real binary location.
+my ($bindir, $stderr);
+my $result = IPC::Run::run [ 'pg_config', '--bindir' ], '>', \$bindir, '2>', \$stderr;
+chomp($bindir);
+
+# Initialize a new node for the upgrade.
+my $newnode = get_new_node('new_node');
+$newnode->init;
+
+# Time for the real run.
+run_log(['pg_upgrade', '-d', $oldnode->data_dir, -D, $newnode->data_dir,
+ '-b', $bindir, '-B', $bindir, '-p', $oldnode->port, '-P', $newnode->port]);
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+run_log(['pg_dumpall', '--port', $newnode->port, '-f', "$tempdir/dump2.sql"]);
+
+# Cleanup the old cluster data.
+my $delete_script = $TestLib::windows_os ? "$startdir/delete_old_cluster.bat" :
+ "$startdir/delete_old_cluster.sh";
+command_ok([$delete_script], "Deletion of old cluster data");
+
+# Compare the two dumps, there should be no differences.
+command_ok(['diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql"],
+ 'Old and new dump checks after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index cbc5259550..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,248 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- "$1" -N
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# Establish how the server will listen for connections
-testhost=`uname -s`
-
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PGHOST=localhost
- ;;
- *)
- 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
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=$LISTEN_ADDRESSES -k \"$PGHOST\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-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"
-
- # 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
- SHLIB_PATH=$libdir:$SHLIB_PATH
- export SHLIB_PATH
- 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
- # be outdated or missing. But don't override anything else that's
- # already in EXTRA_REGRESS_OPTS.
- EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$bindir'"
- export EXTRA_REGRESS_OPTS
-fi
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA=$temp_root/data
-PGDATA="$BASE_PGDATA.old"
-export PGDATA
-rm -rf "$BASE_PGDATA" "$PGDATA"
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-# enable echo so the user can see what is being executed
-set -x
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "$dbname1" || createdb_status=$?
-createdb "$dbname2" || createdb_status=$?
-createdb "$dbname3" || createdb_status=$?
-
-if "$MAKE" -C "$oldsrc" installcheck; then
- pg_dumpall -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
- if [ "$newsrc" != "$oldsrc" ]; then
- oldpgversion=`psql -X -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 -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA=$BASE_PGDATA
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "${PGDATA}" -b "$oldbindir" -B "$bindir" -p "$PGPORT" -P "$PGPORT"
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-case $testhost in
- MINGW*) cmd /c analyze_new_cluster.bat ;;
- *) sh ./analyze_new_cluster.sh ;;
-esac
-
-pg_dumpall -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-# no need to echo commands anymore
-set +x
-echo
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 8933920d9b..7d6fb6200a 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -34,7 +34,7 @@ if (-e "src/tools/msvc/buildenv.pl")
my $what = shift || "";
if ($what =~
-/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|upgradecheck|bincheck|recoverycheck)$/i
+/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|bincheck|recoverycheck)$/i
)
{
$what = uc $what;
@@ -89,8 +89,7 @@ my %command = (
MODULESCHECK => \&modulescheck,
ISOLATIONCHECK => \&isolationcheck,
BINCHECK => \&bincheck,
- RECOVERYCHECK => \&recoverycheck,
- UPGRADECHECK => \&upgradecheck,);
+ RECOVERYCHECK => \&recoverycheck,);
my $proc = $command{$what};
@@ -382,126 +381,6 @@ sub standard_initdb
$ENV{PGDATA}) == 0);
}
-# This is similar to appendShellString(). Perl system(@args) bypasses
-# cmd.exe, so omit the caret escape layer.
-sub quote_system_arg
-{
- my $arg = shift;
-
- # Change N >= 0 backslashes before a double quote to 2N+1 backslashes.
- $arg =~ s/(\\*)"/${\($1 . $1)}\\"/gs;
-
- # Change N >= 1 backslashes at end of argument to 2N backslashes.
- $arg =~ s/(\\+)$/${\($1 . $1)}/gs;
-
- # Wrap the whole thing in unescaped double quotes.
- return "\"$arg\"";
-}
-
-# Generate a database with a name made of a range of ASCII characters, useful
-# for testing pg_upgrade.
-sub generate_db
-{
- my ($prefix, $from_char, $to_char, $suffix) = @_;
-
- my $dbname = $prefix;
- for my $i ($from_char .. $to_char)
- {
- next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
- $dbname = $dbname . sprintf('%c', $i);
- }
- $dbname .= $suffix;
-
- system('createdb', quote_system_arg($dbname));
- my $status = $? >> 8;
- exit $status if $status;
-}
-
-sub upgradecheck
-{
- my $status;
- my $cwd = getcwd();
-
- # Much of this comes from the pg_upgrade test.sh script,
- # but it only covers the --install case, and not the case
- # where the old and new source or bin dirs are different.
- # i.e. only this version to this version check. That's
- # what pg_upgrade's "make check" does.
-
- $ENV{PGHOST} = 'localhost';
- $ENV{PGPORT} ||= 50432;
- my $tmp_root = "$topdir/src/bin/pg_upgrade/tmp_check";
- (mkdir $tmp_root || die $!) unless -d $tmp_root;
- my $upg_tmp_install = "$tmp_root/install"; # unshared temp install
- print "Setting up temp install\n\n";
- Install($upg_tmp_install, "all", $config);
-
- # Install does a chdir, so change back after that
- chdir $cwd;
- my ($bindir, $libdir, $oldsrc, $newsrc) =
- ("$upg_tmp_install/bin", "$upg_tmp_install/lib", $topdir, $topdir);
- $ENV{PATH} = "$bindir;$ENV{PATH}";
- my $data = "$tmp_root/data";
- $ENV{PGDATA} = "$data.old";
- my $logdir = "$topdir/src/bin/pg_upgrade/log";
- (mkdir $logdir || die $!) unless -d $logdir;
- print "\nRunning initdb on old cluster\n\n";
- standard_initdb() or exit 1;
- print "\nStarting old cluster\n\n";
- my @args = ('pg_ctl', 'start', '-l', "$logdir/postmaster1.log");
- system(@args) == 0 or exit 1;
-
- print "\nCreating databases with names covering most ASCII bytes\n\n";
- generate_db("\\\"\\", 1, 45, "\\\\\"\\\\\\");
- generate_db('', 46, 90, '');
- generate_db('', 91, 127, '');
-
- print "\nSetting up data for upgrading\n\n";
- installcheck();
-
- # now we can chdir into the source dir
- chdir "$topdir/src/bin/pg_upgrade";
- print "\nDumping old cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump1.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping old cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- $ENV{PGDATA} = "$data";
- print "\nSetting up new cluster\n\n";
- standard_initdb() or exit 1;
- print "\nRunning pg_upgrade\n\n";
- @args = (
- 'pg_upgrade', '-d', "$data.old", '-D', $data, '-b',
- $bindir, '-B', $bindir);
- system(@args) == 0 or exit 1;
- print "\nStarting new cluster\n\n";
- @args = ('pg_ctl', '-l', "$logdir/postmaster2.log", 'start');
- system(@args) == 0 or exit 1;
- print "\nSetting up stats on new cluster\n\n";
- system(".\\analyze_new_cluster.bat") == 0 or exit 1;
- print "\nDumping new cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump2.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping new cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- print "\nDeleting old cluster\n\n";
- system(".\\delete_old_cluster.bat") == 0 or exit 1;
- print "\nComparing old and new cluster dumps\n\n";
-
- @args = ('diff', '-q', "$tmp_root/dump1.sql", "$tmp_root/dump2.sql");
- system(@args);
- $status = $?;
- if (!$status)
- {
- print "PASSED\n";
- }
- else
- {
- print "dumps not identical!\n";
- exit(1);
- }
-}
-
sub fetchRegressOpts
{
my $handle;
@@ -607,7 +486,6 @@ sub usage
" modulescheck run tests of modules in src/test/modules/\n",
" plcheck run tests of PL languages\n",
" recoverycheck run recovery test suite\n",
- " upgradecheck run tests of pg_upgrade\n",
"\nOptions for <schedule>:\n",
" serial serial mode\n",
" parallel parallel mode\n";
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-04-05 13:24 ` Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Stephen Frost @ 2017-04-05 13:24 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
Michael,
* Michael Paquier ([email protected]) wrote:
> On Tue, Apr 4, 2017 at 9:30 PM, Stephen Frost <[email protected]> wrote:
> > * Michael Paquier ([email protected]) wrote:
> >> On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost <[email protected]> wrote:
> >> The patch presented here does lower the coverage we have now.
> >
> > I assume (perhaps mistakenly) that this statement was based on an
> > analysis of before-and-after 'make coverage' runs. Here you are saying
> > that you're *not* lowering the coverage.
>
> My apologies here, when I used the work "coverage" in my previous
> emails it visibly implied that I meant that I had used the coverage
> stuff. But I did not because the TAP test proposed does exactly what
> test.sh is doing:
Ah, ok, no worries. Glad to hear that there isn't any difference in
coverage or in what's being done.
> 1) Initialize the old cluster and start it.
> 2) create a bunch of databases with full range of ascii characters.
> 3) Run regression tests.
> 4) Take dump on old cluster.
> 4) Stop the old cluster.
> 5) Initialize the new cluster.
> 6) Run pg_upgrade.
> 7) Start new cluster.
> 8) Take dump from it.
> 9) Run deletion script (Oops forgot this part!)
Presumably the check to match the old dump against the new one is also
performed?
> > I understand how the current pg_upgrade tests work. I don't see
> > off-hand why the TAP tests would reduce the code coverage of pg_upgrade,
> > but if they do, we should be able to figure out why and correct it.
>
> Good news is that this patch at least does not lower the bar.
Great, then I don't see any reason we can't move forward with it.
> > What I do think is a barrier to this patch moving forward is if it
> > reduces our current code coverage testing (with the same-version
> > pg_upgrade that's run in the regular regression tests). If it doesn't,
> > then great, but if it does, then the patch should be updated to fix
> > that.
>
> I did not do a coverage test first, but surely this patch needs
> numbers, so here you go.
>
> Without the patch, here is the coverage of src/bin/pg_upgrade:
> lines......: 57.7% (1311 of 2273 lines)
> functions..: 85.3% (87 of 102 functions)
>
> And with the patch:
> lines......: 58.8% (1349 of 2294 lines)
> functions..: 85.6% (89 of 104 functions)
> The coverage gets a bit higher as a couple of basic code paths like
> pg_upgrade --help get looked at.
Fantastic, that's even better.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-05 22:48 ` Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-04-05 22:48 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
On Wed, Apr 5, 2017 at 10:24 PM, Stephen Frost <[email protected]> wrote:
> * Michael Paquier ([email protected]) wrote:
>> 1) Initialize the old cluster and start it.
>> 2) create a bunch of databases with full range of ascii characters.
>> 3) Run regression tests.
>> 4) Take dump on old cluster.
>> 4) Stop the old cluster.
>> 5) Initialize the new cluster.
>> 6) Run pg_upgrade.
>> 7) Start new cluster.
>> 8) Take dump from it.
>> 9) Run deletion script (Oops forgot this part!)
>
> Presumably the check to match the old dump against the new one is also
> performed?
Yes. That's run with command_ok() at the end.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-04-14 06:00 ` Michael Paquier <[email protected]>
2017-04-14 11:03 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
0 siblings, 2 replies; 118+ messages in thread
From: Michael Paquier @ 2017-04-14 06:00 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
On Thu, Apr 6, 2017 at 7:48 AM, Michael Paquier
<[email protected]> wrote:
> On Wed, Apr 5, 2017 at 10:24 PM, Stephen Frost <[email protected]> wrote:
>> * Michael Paquier ([email protected]) wrote:
>>> 1) Initialize the old cluster and start it.
>>> 2) create a bunch of databases with full range of ascii characters.
>>> 3) Run regression tests.
>>> 4) Take dump on old cluster.
>>> 4) Stop the old cluster.
>>> 5) Initialize the new cluster.
>>> 6) Run pg_upgrade.
>>> 7) Start new cluster.
>>> 8) Take dump from it.
>>> 9) Run deletion script (Oops forgot this part!)
>>
>> Presumably the check to match the old dump against the new one is also
>> performed?
>
> Yes. That's run with command_ok() at the end.
Attached is an updated patch to use --no-sync with pg_dumpall calls.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] pgupgrade-tap-test-v3.patch (17.9K, ../../CAB7nPqTxoNiC62NSTwjk6nb62wf0C20x1QtBnpGdHNn6r=3dZw@mail.gmail.com/2-pgupgrade-tap-test-v3.patch)
download | inline diff:
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index f5dfb91ac1..a4678462c3 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -444,7 +444,6 @@ $ENV{CONFIG}="Debug";
<userinput>vcregress isolationcheck</userinput>
<userinput>vcregress bincheck</userinput>
<userinput>vcregress recoverycheck</userinput>
-<userinput>vcregress upgradecheck</userinput>
</screen>
To change the schedule used (default is parallel), append it to the
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 8823288708..a78b39f3e5 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -35,9 +35,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-check: test.sh all
- MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $< --install
+check:
+ $(prove_check)
-# disabled because it upsets the build farm
-#installcheck: test.sh
-# MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) $(SHELL) $<
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
index 4ecfc5798e..4885164d04 100644
--- a/src/bin/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -61,7 +61,7 @@ steps:
7) Diff the regression database dump file with the regression dump
file loaded into the old server.
-The shell script test.sh in this directory performs more or less this
+The TAP test scripts in this directory perform more or less this
procedure. You can invoke it by running
make check
@@ -69,13 +69,3 @@ procedure. You can invoke it by running
or by running
make installcheck
-
-if "make install" (or "make install-world") were done beforehand.
-When invoked without arguments, it will run 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, invoke it like this:
-
- make installcheck oldbindir=...otherversion/bin oldsrc=...somewhere/postgresql
-
-In this case, you will have to manually eyeball the resulting dump
-diff for version-specific differences, as explained above.
diff --git a/src/bin/pg_upgrade/t/010_pg_upgrade.pl b/src/bin/pg_upgrade/t/010_pg_upgrade.pl
new file mode 100644
index 0000000000..a58ee267bc
--- /dev/null
+++ b/src/bin/pg_upgrade/t/010_pg_upgrade.pl
@@ -0,0 +1,93 @@
+# Set of tests for pg_upgrade.
+use strict;
+use warnings;
+use Cwd;
+use Config;
+use File::Basename;
+use IPC::Run;
+use PostgresNode;
+use TestLib;
+use Test::More tests => 9;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log([ 'createdb', '--port', $node->port, $dbname ]);
+}
+
+my $startdir = getcwd();
+
+# From now on, the test of pg_upgrade consists in setting up an instance
+# on which regression tests are run. This is the source instance used
+# for the upgrade. Then a new, fresh instance is created, and is used
+# as the target instance for the upgrade. Before running an upgrade a
+# logical dump of the old instance is taken, and a second logical dump
+# of the new instance is taken after the upgrade. The upgrade test
+# passes if there are no differences after running pg_upgrade.
+
+# Temporary location for dumps taken
+my $tempdir = TestLib::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = get_new_node('old_node');
+$oldnode->init;
+$oldnode->start;
+
+# Creating databases with names covering most ASCII bytes
+generate_db($oldnode, 1, 45);
+generate_db($oldnode, 46, 90);
+generate_db($oldnode, 91, 127);
+
+# Run regression tests on the old instance
+chdir dirname($ENV{PG_REGRESS});
+$oldnode->run_log([ 'createdb', '--port', $oldnode->port, 'regression' ]);
+run_log([$ENV{PG_REGRESS}, '--schedule', './serial_schedule',
+ '--dlpath', '.', '--bindir=', '--use-existing',
+ '--port', $oldnode->port]);
+
+# Take a dump before performing the upgrade as a base comparison.
+run_log(['pg_dumpall', '--no-sync', '--port', $oldnode->port,
+ '-f', "$tempdir/dump1.sql"]);
+
+# Move back to current directory, all logs generated need to be located
+# at the origin.
+chdir $startdir;
+
+# Update the instance.
+$oldnode->stop;
+
+# pg_upgrade needs the location of the old and new binaries. This test
+# relying on binaries being in PATH, so is pg_config. So fetch from it
+# the real binary location.
+my ($bindir, $stderr);
+my $result = IPC::Run::run [ 'pg_config', '--bindir' ], '>', \$bindir, '2>', \$stderr;
+chomp($bindir);
+
+# Initialize a new node for the upgrade.
+my $newnode = get_new_node('new_node');
+$newnode->init;
+
+# Time for the real run.
+run_log(['pg_upgrade', '-d', $oldnode->data_dir, -D, $newnode->data_dir,
+ '-b', $bindir, '-B', $bindir, '-p', $oldnode->port, '-P', $newnode->port]);
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+run_log(['pg_dumpall', '--no-sync', '--port', $newnode->port,
+ '-f', "$tempdir/dump2.sql"]);
+
+# Compare the two dumps, there should be no differences.
+command_ok(['diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql"],
+ 'Old and new dump checks after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index 841da034b0..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,248 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- "$1" -N
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# Establish how the server will listen for connections
-testhost=`uname -s`
-
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PGHOST=localhost
- ;;
- *)
- 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
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=$LISTEN_ADDRESSES -k \"$PGHOST\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-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"
-
- # 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
- SHLIB_PATH=$libdir:$SHLIB_PATH
- export SHLIB_PATH
- 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
- # be outdated or missing. But don't override anything else that's
- # already in EXTRA_REGRESS_OPTS.
- EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$bindir'"
- export EXTRA_REGRESS_OPTS
-fi
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA=$temp_root/data
-PGDATA="$BASE_PGDATA.old"
-export PGDATA
-rm -rf "$BASE_PGDATA" "$PGDATA"
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-# enable echo so the user can see what is being executed
-set -x
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "$dbname1" || createdb_status=$?
-createdb "$dbname2" || createdb_status=$?
-createdb "$dbname3" || createdb_status=$?
-
-if "$MAKE" -C "$oldsrc" installcheck; then
- pg_dumpall --no-sync -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
- if [ "$newsrc" != "$oldsrc" ]; then
- oldpgversion=`psql -X -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 -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA=$BASE_PGDATA
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "${PGDATA}" -b "$oldbindir" -B "$bindir" -p "$PGPORT" -P "$PGPORT"
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-case $testhost in
- MINGW*) cmd /c analyze_new_cluster.bat ;;
- *) sh ./analyze_new_cluster.sh ;;
-esac
-
-pg_dumpall --no-sync -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-# no need to echo commands anymore
-set +x
-echo
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 8933920d9b..7d6fb6200a 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -34,7 +34,7 @@ if (-e "src/tools/msvc/buildenv.pl")
my $what = shift || "";
if ($what =~
-/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|upgradecheck|bincheck|recoverycheck)$/i
+/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|bincheck|recoverycheck)$/i
)
{
$what = uc $what;
@@ -89,8 +89,7 @@ my %command = (
MODULESCHECK => \&modulescheck,
ISOLATIONCHECK => \&isolationcheck,
BINCHECK => \&bincheck,
- RECOVERYCHECK => \&recoverycheck,
- UPGRADECHECK => \&upgradecheck,);
+ RECOVERYCHECK => \&recoverycheck,);
my $proc = $command{$what};
@@ -382,126 +381,6 @@ sub standard_initdb
$ENV{PGDATA}) == 0);
}
-# This is similar to appendShellString(). Perl system(@args) bypasses
-# cmd.exe, so omit the caret escape layer.
-sub quote_system_arg
-{
- my $arg = shift;
-
- # Change N >= 0 backslashes before a double quote to 2N+1 backslashes.
- $arg =~ s/(\\*)"/${\($1 . $1)}\\"/gs;
-
- # Change N >= 1 backslashes at end of argument to 2N backslashes.
- $arg =~ s/(\\+)$/${\($1 . $1)}/gs;
-
- # Wrap the whole thing in unescaped double quotes.
- return "\"$arg\"";
-}
-
-# Generate a database with a name made of a range of ASCII characters, useful
-# for testing pg_upgrade.
-sub generate_db
-{
- my ($prefix, $from_char, $to_char, $suffix) = @_;
-
- my $dbname = $prefix;
- for my $i ($from_char .. $to_char)
- {
- next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
- $dbname = $dbname . sprintf('%c', $i);
- }
- $dbname .= $suffix;
-
- system('createdb', quote_system_arg($dbname));
- my $status = $? >> 8;
- exit $status if $status;
-}
-
-sub upgradecheck
-{
- my $status;
- my $cwd = getcwd();
-
- # Much of this comes from the pg_upgrade test.sh script,
- # but it only covers the --install case, and not the case
- # where the old and new source or bin dirs are different.
- # i.e. only this version to this version check. That's
- # what pg_upgrade's "make check" does.
-
- $ENV{PGHOST} = 'localhost';
- $ENV{PGPORT} ||= 50432;
- my $tmp_root = "$topdir/src/bin/pg_upgrade/tmp_check";
- (mkdir $tmp_root || die $!) unless -d $tmp_root;
- my $upg_tmp_install = "$tmp_root/install"; # unshared temp install
- print "Setting up temp install\n\n";
- Install($upg_tmp_install, "all", $config);
-
- # Install does a chdir, so change back after that
- chdir $cwd;
- my ($bindir, $libdir, $oldsrc, $newsrc) =
- ("$upg_tmp_install/bin", "$upg_tmp_install/lib", $topdir, $topdir);
- $ENV{PATH} = "$bindir;$ENV{PATH}";
- my $data = "$tmp_root/data";
- $ENV{PGDATA} = "$data.old";
- my $logdir = "$topdir/src/bin/pg_upgrade/log";
- (mkdir $logdir || die $!) unless -d $logdir;
- print "\nRunning initdb on old cluster\n\n";
- standard_initdb() or exit 1;
- print "\nStarting old cluster\n\n";
- my @args = ('pg_ctl', 'start', '-l', "$logdir/postmaster1.log");
- system(@args) == 0 or exit 1;
-
- print "\nCreating databases with names covering most ASCII bytes\n\n";
- generate_db("\\\"\\", 1, 45, "\\\\\"\\\\\\");
- generate_db('', 46, 90, '');
- generate_db('', 91, 127, '');
-
- print "\nSetting up data for upgrading\n\n";
- installcheck();
-
- # now we can chdir into the source dir
- chdir "$topdir/src/bin/pg_upgrade";
- print "\nDumping old cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump1.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping old cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- $ENV{PGDATA} = "$data";
- print "\nSetting up new cluster\n\n";
- standard_initdb() or exit 1;
- print "\nRunning pg_upgrade\n\n";
- @args = (
- 'pg_upgrade', '-d', "$data.old", '-D', $data, '-b',
- $bindir, '-B', $bindir);
- system(@args) == 0 or exit 1;
- print "\nStarting new cluster\n\n";
- @args = ('pg_ctl', '-l', "$logdir/postmaster2.log", 'start');
- system(@args) == 0 or exit 1;
- print "\nSetting up stats on new cluster\n\n";
- system(".\\analyze_new_cluster.bat") == 0 or exit 1;
- print "\nDumping new cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump2.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping new cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- print "\nDeleting old cluster\n\n";
- system(".\\delete_old_cluster.bat") == 0 or exit 1;
- print "\nComparing old and new cluster dumps\n\n";
-
- @args = ('diff', '-q', "$tmp_root/dump1.sql", "$tmp_root/dump2.sql");
- system(@args);
- $status = $?;
- if (!$status)
- {
- print "PASSED\n";
- }
- else
- {
- print "dumps not identical!\n";
- exit(1);
- }
-}
-
sub fetchRegressOpts
{
my $handle;
@@ -607,7 +486,6 @@ sub usage
" modulescheck run tests of modules in src/test/modules/\n",
" plcheck run tests of PL languages\n",
" recoverycheck run recovery test suite\n",
- " upgradecheck run tests of pg_upgrade\n",
"\nOptions for <schedule>:\n",
" serial serial mode\n",
" parallel parallel mode\n";
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-04-14 11:03 ` Stephen Frost <[email protected]>
2017-04-14 12:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Stephen Frost @ 2017-04-14 11:03 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
Michael,
* Michael Paquier ([email protected]) wrote:
> On Thu, Apr 6, 2017 at 7:48 AM, Michael Paquier
> <[email protected]> wrote:
> > On Wed, Apr 5, 2017 at 10:24 PM, Stephen Frost <[email protected]> wrote:
> >> * Michael Paquier ([email protected]) wrote:
> >>> 1) Initialize the old cluster and start it.
> >>> 2) create a bunch of databases with full range of ascii characters.
> >>> 3) Run regression tests.
> >>> 4) Take dump on old cluster.
> >>> 4) Stop the old cluster.
> >>> 5) Initialize the new cluster.
> >>> 6) Run pg_upgrade.
> >>> 7) Start new cluster.
> >>> 8) Take dump from it.
> >>> 9) Run deletion script (Oops forgot this part!)
> >>
> >> Presumably the check to match the old dump against the new one is also
> >> performed?
> >
> > Yes. That's run with command_ok() at the end.
>
> Attached is an updated patch to use --no-sync with pg_dumpall calls.
Some of those were specifically left around to test those code paths.
I'm not sure if these were those or not though, Andrew was the one who
reviewed the various pg_dumpall calls to add --no-sync in places.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 11:03 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-14 12:22 ` Michael Paquier <[email protected]>
2017-04-14 12:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-04-14 12:22 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
On Fri, Apr 14, 2017 at 8:03 PM, Stephen Frost <[email protected]> wrote:
> Some of those were specifically left around to test those code paths.
> I'm not sure if these were those or not though, Andrew was the one who
> reviewed the various pg_dumpall calls to add --no-sync in places.
Well, Andrew has pushed the patch I have written, and the calls of
pg_dumpall in pg_upgrade use --no-sync. The ones intentionally left
are in src/bin/pg_dump/t/002_pg_dump.pl.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 11:03 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-14 12:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-04-14 12:24 ` Stephen Frost <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Stephen Frost @ 2017-04-14 12:24 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Craig Ringer <[email protected]>; Noah Misch <[email protected]>; pgsql-hackers
* Michael Paquier ([email protected]) wrote:
> On Fri, Apr 14, 2017 at 8:03 PM, Stephen Frost <[email protected]> wrote:
> > Some of those were specifically left around to test those code paths.
> > I'm not sure if these were those or not though, Andrew was the one who
> > reviewed the various pg_dumpall calls to add --no-sync in places.
>
> Well, Andrew has pushed the patch I have written, and the calls of
> pg_dumpall in pg_upgrade use --no-sync. The ones intentionally left
> are in src/bin/pg_dump/t/002_pg_dump.pl.
Ok. :)
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-09-06 13:05 ` Peter Eisentraut <[email protected]>
2017-09-06 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Alvaro Herrera <[email protected]>
2017-09-07 02:14 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
1 sibling, 2 replies; 118+ messages in thread
From: Peter Eisentraut @ 2017-09-06 13:05 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: pgsql-hackers
On 4/14/17 02:00, Michael Paquier wrote:
> Attached is an updated patch to use --no-sync with pg_dumpall calls.
Please send a rebased patch.
I propose splitting the single Perl script into three separate test
files: one for basic command-line option handling and so on (I would
like to expand that later), one for the main upgrade test, and one for
the funny database names tests.
In the testing file, you removed the paragraph that explains how to do
cross-version upgrade testing. It's unfortunate that we would lose that
functionality. What can we do about that?
We also need to have a plan for handling the build farm. Maybe keep the
vcregress.pl upgradecheck target as a thin wrapper for the time being?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
@ 2017-09-06 13:52 ` Alvaro Herrera <[email protected]>
2017-09-06 14:44 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Alvaro Herrera @ 2017-09-06 13:52 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
Peter Eisentraut wrote:
> I propose splitting the single Perl script into three separate test
> files: one for basic command-line option handling and so on (I would
> like to expand that later), one for the main upgrade test, and one for
> the funny database names tests.
Check.
> We also need to have a plan for handling the build farm. Maybe keep the
> vcregress.pl upgradecheck target as a thin wrapper for the time being?
The buildfarm already runs "make check" in src/bin/ when TAP tests are
enabled, which should be enough to trigger the rewritten test, no?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-06 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Alvaro Herrera <[email protected]>
@ 2017-09-06 14:44 ` Tom Lane <[email protected]>
2017-09-07 01:37 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Tom Lane @ 2017-09-06 14:44 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
Alvaro Herrera <[email protected]> writes:
> Peter Eisentraut wrote:
>> We also need to have a plan for handling the build farm. Maybe keep the
>> vcregress.pl upgradecheck target as a thin wrapper for the time being?
> The buildfarm already runs "make check" in src/bin/ when TAP tests are
> enabled, which should be enough to trigger the rewritten test, no?
I think Peter's on about the Windows case. Not sure how that's handled,
but it's not "make check".
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-06 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Alvaro Herrera <[email protected]>
2017-09-06 14:44 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
@ 2017-09-07 01:37 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2017-09-07 01:37 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On Wed, Sep 6, 2017 at 11:44 PM, Tom Lane <[email protected]> wrote:
> Alvaro Herrera <[email protected]> writes:
>> Peter Eisentraut wrote:
>>> We also need to have a plan for handling the build farm. Maybe keep the
>>> vcregress.pl upgradecheck target as a thin wrapper for the time being?
>
>> The buildfarm already runs "make check" in src/bin/ when TAP tests are
>> enabled, which should be enough to trigger the rewritten test, no?
>
> I think Peter's on about the Windows case. Not sure how that's handled,
> but it's not "make check".
For MSVC, one can use "vcregress.bat upgradecheck". So perhaps we
could keep upgradecheck for a short time but make it a noop instead
with this patch, and then remove it once buildfarm animals are
upgraded to a newer client version? I would prefer seeing a simple
removal of upgradecheck at the end, and put all TAP tests for binaries
under the bincheck path. This feels more natural.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
@ 2017-09-07 02:14 ` Michael Paquier <[email protected]>
2017-09-19 04:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-09-07 02:14 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: pgsql-hackers
On Wed, Sep 6, 2017 at 10:05 PM, Peter Eisentraut
<[email protected]> wrote:
> Please send a rebased patch.
>
> I propose splitting the single Perl script into three separate test
> files: one for basic command-line option handling and so on (I would
> like to expand that later), one for the main upgrade test, and one for
> the funny database names tests.
That makes sense. There will be additional overhead with the creation
of an extra server though.
> In the testing file, you removed the paragraph that explains how to do
> cross-version upgrade testing. It's unfortunate that we would lose that
> functionality. What can we do about that?
Right, simply removing support for something which has been here for a
long time is no fun. I think that we should add in PostgresNode
objects a new bindir variable which will be used to define path to
binaries. Any new node created needs to go through init() or
init_from_backup(), so a node created with init() would set this
bindir to what pg_config in PATH reports, or to the value defined by
the caller if it is defined (let's use an option for %params). A node
created from init_from_backup() inherits the path of its root node.
This requires a bit of refactoring first. This could help also for
cross version tests out of the code core.
In the existing scripts, there are the following variables:
- oldsrc, old version's source tree
- oldbindir, old version's installed bin dir
- bindir, this version's installed bin dir.
- libdir, this version's installed lib dir
bindir and libdir are pointing to the currently installed version in
the tree, so we could do without it, no? oldbindir and oldsrc need to
be kept around to enforce the position of binaries for the old
version, as well as a proper shape of the original dump being compared
(+ drop of the past functions).
Then, for the pg_upgrade tests, let's check for ENV{oldbindir} and
enforce the bindir value of the PostgresNode to-be-upgraded. And also
for ENV{oldsrc}, first check if it is defined, and then do the
existing psql/dump changes. So one, in order to run cross-version
checks, would just need to rely on the fact that the version where
installcheck runs is the new version. Does that sound acceptable?
Looking at 5bab198, those don't run that often, but I definitely agree
that breaking something for no apparent reason is not cool either ;p
> We also need to have a plan for handling the build farm. Maybe keep the
> vcregress.pl upgradecheck target as a thin wrapper for the time being?
Or we could make upgradecheck a noop, then remove it once all the MSVC
animals have upgraded to a newer version of the buildfarm client which
does not use upgradecheck anymore (I am fine to send a patch or a pull
request to Andrew for that).
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-07 02:14 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-09-19 04:30 ` Michael Paquier <[email protected]>
2017-09-19 09:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-09-19 04:30 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: pgsql-hackers
On Thu, Sep 7, 2017 at 11:14 AM, Michael Paquier
<[email protected]> wrote:
> Or we could make upgradecheck a noop, then remove it once all the MSVC
> animals have upgraded to a newer version of the buildfarm client which
> does not use upgradecheck anymore (I am fine to send a patch or a pull
> request to Andrew for that).
This patch is logged as "waiting on author" in the current commit
fest, but any new patch will depend on the feedback that any other
hacker has to offer based on the set of ideas I have posted upthread.
Hence I am yet unsure what is the correct way to move things forward.
So, any opinions? Peter or others?
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-07 02:14 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 04:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-09-19 09:15 ` Alvaro Herrera <[email protected]>
2017-09-19 11:37 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Alvaro Herrera @ 2017-09-19 09:15 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
Michael Paquier wrote:
> On Thu, Sep 7, 2017 at 11:14 AM, Michael Paquier
> <[email protected]> wrote:
> > Or we could make upgradecheck a noop, then remove it once all the MSVC
> > animals have upgraded to a newer version of the buildfarm client which
> > does not use upgradecheck anymore (I am fine to send a patch or a pull
> > request to Andrew for that).
>
> This patch is logged as "waiting on author" in the current commit
> fest, but any new patch will depend on the feedback that any other
> hacker has to offer based on the set of ideas I have posted upthread.
> Hence I am yet unsure what is the correct way to move things forward.
> So, any opinions? Peter or others?
I think the first step is to send the rebased version of the patch. It
was last posted in April ...
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-07 02:14 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 04:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 09:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Alvaro Herrera <[email protected]>
@ 2017-09-19 11:37 ` Michael Paquier <[email protected]>
2017-09-19 22:57 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-09-19 11:37 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; pgsql-hackers
On Tue, Sep 19, 2017 at 6:15 PM, Alvaro Herrera <[email protected]> wrote:
> Michael Paquier wrote:
>> On Thu, Sep 7, 2017 at 11:14 AM, Michael Paquier
>> <[email protected]> wrote:
>> > Or we could make upgradecheck a noop, then remove it once all the MSVC
>> > animals have upgraded to a newer version of the buildfarm client which
>> > does not use upgradecheck anymore (I am fine to send a patch or a pull
>> > request to Andrew for that).
>>
>> This patch is logged as "waiting on author" in the current commit
>> fest, but any new patch will depend on the feedback that any other
>> hacker has to offer based on the set of ideas I have posted upthread.
>> Hence I am yet unsure what is the correct way to move things forward.
>> So, any opinions? Peter or others?
>
> I think the first step is to send the rebased version of the patch. It
> was last posted in April ...
Here you go. I have not done anything fancy for cross-version tests yet.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
[application/octet-stream] pgupgrade-tap-test-v4.patch (17.1K, ../../CAB7nPqRJXz0sEuUL36eBsF7iZtOQGMJoJPGFWxHLuS6TYPxf5w@mail.gmail.com/2-pgupgrade-tap-test-v4.patch)
download | inline diff:
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 1861e7e2f7..4ac6920f2c 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -445,7 +445,6 @@ $ENV{CONFIG}="Debug";
<userinput>vcregress isolationcheck</userinput>
<userinput>vcregress bincheck</userinput>
<userinput>vcregress recoverycheck</userinput>
-<userinput>vcregress upgradecheck</userinput>
</screen>
To change the schedule used (default is parallel), append it to the
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 1d6ee702c6..bccab1d723 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -36,8 +36,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-check: test.sh all
- MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $< --install
+check:
+ $(prove_check)
-# installcheck is not supported because there's no meaningful way to test
-# pg_upgrade against a single already-running server
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/t/010_pg_upgrade.pl b/src/bin/pg_upgrade/t/010_pg_upgrade.pl
new file mode 100644
index 0000000000..a58ee267bc
--- /dev/null
+++ b/src/bin/pg_upgrade/t/010_pg_upgrade.pl
@@ -0,0 +1,93 @@
+# Set of tests for pg_upgrade.
+use strict;
+use warnings;
+use Cwd;
+use Config;
+use File::Basename;
+use IPC::Run;
+use PostgresNode;
+use TestLib;
+use Test::More tests => 9;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log([ 'createdb', '--port', $node->port, $dbname ]);
+}
+
+my $startdir = getcwd();
+
+# From now on, the test of pg_upgrade consists in setting up an instance
+# on which regression tests are run. This is the source instance used
+# for the upgrade. Then a new, fresh instance is created, and is used
+# as the target instance for the upgrade. Before running an upgrade a
+# logical dump of the old instance is taken, and a second logical dump
+# of the new instance is taken after the upgrade. The upgrade test
+# passes if there are no differences after running pg_upgrade.
+
+# Temporary location for dumps taken
+my $tempdir = TestLib::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = get_new_node('old_node');
+$oldnode->init;
+$oldnode->start;
+
+# Creating databases with names covering most ASCII bytes
+generate_db($oldnode, 1, 45);
+generate_db($oldnode, 46, 90);
+generate_db($oldnode, 91, 127);
+
+# Run regression tests on the old instance
+chdir dirname($ENV{PG_REGRESS});
+$oldnode->run_log([ 'createdb', '--port', $oldnode->port, 'regression' ]);
+run_log([$ENV{PG_REGRESS}, '--schedule', './serial_schedule',
+ '--dlpath', '.', '--bindir=', '--use-existing',
+ '--port', $oldnode->port]);
+
+# Take a dump before performing the upgrade as a base comparison.
+run_log(['pg_dumpall', '--no-sync', '--port', $oldnode->port,
+ '-f', "$tempdir/dump1.sql"]);
+
+# Move back to current directory, all logs generated need to be located
+# at the origin.
+chdir $startdir;
+
+# Update the instance.
+$oldnode->stop;
+
+# pg_upgrade needs the location of the old and new binaries. This test
+# relying on binaries being in PATH, so is pg_config. So fetch from it
+# the real binary location.
+my ($bindir, $stderr);
+my $result = IPC::Run::run [ 'pg_config', '--bindir' ], '>', \$bindir, '2>', \$stderr;
+chomp($bindir);
+
+# Initialize a new node for the upgrade.
+my $newnode = get_new_node('new_node');
+$newnode->init;
+
+# Time for the real run.
+run_log(['pg_upgrade', '-d', $oldnode->data_dir, -D, $newnode->data_dir,
+ '-b', $bindir, '-B', $bindir, '-p', $oldnode->port, '-P', $newnode->port]);
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+run_log(['pg_dumpall', '--no-sync', '--port', $newnode->port,
+ '-f', "$tempdir/dump2.sql"]);
+
+# Compare the two dumps, there should be no differences.
+command_ok(['diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql"],
+ 'Old and new dump checks after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index f4556341f3..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,262 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- "$1" -N
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# Establish how the server will listen for connections
-testhost=`uname -s`
-
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PGHOST=localhost
- ;;
- *)
- 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
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=$LISTEN_ADDRESSES -k \"$PGHOST\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-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"
-
- # 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
- SHLIB_PATH=$libdir:$SHLIB_PATH
- export SHLIB_PATH
- 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
- # be outdated or missing. But don't override anything else that's
- # already in EXTRA_REGRESS_OPTS.
- EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$bindir'"
- export EXTRA_REGRESS_OPTS
-fi
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA=$temp_root/data
-PGDATA="$BASE_PGDATA.old"
-export PGDATA
-rm -rf "$BASE_PGDATA" "$PGDATA"
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-# enable echo so the user can see what is being executed
-set -x
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "$dbname1" || createdb_status=$?
-createdb "$dbname2" || createdb_status=$?
-createdb "$dbname3" || createdb_status=$?
-
-if "$MAKE" -C "$oldsrc" installcheck; then
- oldpgversion=`psql -X -A -t -d regression -c "SHOW server_version_num"`
-
- # before dumping, get rid of objects not existing in later versions
- if [ "$newsrc" != "$oldsrc" ]; then
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="DROP FUNCTION public.myfunc(integer); DROP FUNCTION public.oldstyle_length(integer, text);"
- ;;
- *)
- fix_sql="DROP FUNCTION public.oldstyle_length(integer, text);"
- ;;
- esac
- psql -X -d regression -c "$fix_sql;" || psql_fix_sql_status=$?
- fi
-
- pg_dumpall --no-sync -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
-
- if [ "$newsrc" != "$oldsrc" ]; then
- # update references to old source tree's regress.so etc
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%';"
- ;;
- *)
- fix_sql="UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';"
- ;;
- esac
- psql -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA=$BASE_PGDATA
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "${PGDATA}" -b "$oldbindir" -B "$bindir" -p "$PGPORT" -P "$PGPORT"
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-case $testhost in
- MINGW*) cmd /c analyze_new_cluster.bat ;;
- *) sh ./analyze_new_cluster.sh ;;
-esac
-
-pg_dumpall --no-sync -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-# no need to echo commands anymore
-set +x
-echo
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 2904679114..3a91f99525 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -34,7 +34,7 @@ if (-e "src/tools/msvc/buildenv.pl")
my $what = shift || "";
if ($what =~
-/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|upgradecheck|bincheck|recoverycheck|taptest)$/i
+/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|bincheck|recoverycheck|taptest)$/i
)
{
$what = uc $what;
@@ -83,7 +83,6 @@ my %command = (
ISOLATIONCHECK => \&isolationcheck,
BINCHECK => \&bincheck,
RECOVERYCHECK => \&recoverycheck,
- UPGRADECHECK => \&upgradecheck,
TAPTEST => \&taptest,);
my $proc = $command{$what};
@@ -407,126 +406,6 @@ sub standard_initdb
$ENV{PGDATA}) == 0);
}
-# This is similar to appendShellString(). Perl system(@args) bypasses
-# cmd.exe, so omit the caret escape layer.
-sub quote_system_arg
-{
- my $arg = shift;
-
- # Change N >= 0 backslashes before a double quote to 2N+1 backslashes.
- $arg =~ s/(\\*)"/${\($1 . $1)}\\"/gs;
-
- # Change N >= 1 backslashes at end of argument to 2N backslashes.
- $arg =~ s/(\\+)$/${\($1 . $1)}/gs;
-
- # Wrap the whole thing in unescaped double quotes.
- return "\"$arg\"";
-}
-
-# Generate a database with a name made of a range of ASCII characters, useful
-# for testing pg_upgrade.
-sub generate_db
-{
- my ($prefix, $from_char, $to_char, $suffix) = @_;
-
- my $dbname = $prefix;
- for my $i ($from_char .. $to_char)
- {
- next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
- $dbname = $dbname . sprintf('%c', $i);
- }
- $dbname .= $suffix;
-
- system('createdb', quote_system_arg($dbname));
- my $status = $? >> 8;
- exit $status if $status;
-}
-
-sub upgradecheck
-{
- my $status;
- my $cwd = getcwd();
-
- # Much of this comes from the pg_upgrade test.sh script,
- # but it only covers the --install case, and not the case
- # where the old and new source or bin dirs are different.
- # i.e. only this version to this version check. That's
- # what pg_upgrade's "make check" does.
-
- $ENV{PGHOST} = 'localhost';
- $ENV{PGPORT} ||= 50432;
- my $tmp_root = "$topdir/src/bin/pg_upgrade/tmp_check";
- (mkdir $tmp_root || die $!) unless -d $tmp_root;
- my $upg_tmp_install = "$tmp_root/install"; # unshared temp install
- print "Setting up temp install\n\n";
- Install($upg_tmp_install, "all", $config);
-
- # Install does a chdir, so change back after that
- chdir $cwd;
- my ($bindir, $libdir, $oldsrc, $newsrc) =
- ("$upg_tmp_install/bin", "$upg_tmp_install/lib", $topdir, $topdir);
- $ENV{PATH} = "$bindir;$ENV{PATH}";
- my $data = "$tmp_root/data";
- $ENV{PGDATA} = "$data.old";
- my $logdir = "$topdir/src/bin/pg_upgrade/log";
- (mkdir $logdir || die $!) unless -d $logdir;
- print "\nRunning initdb on old cluster\n\n";
- standard_initdb() or exit 1;
- print "\nStarting old cluster\n\n";
- my @args = ('pg_ctl', 'start', '-l', "$logdir/postmaster1.log");
- system(@args) == 0 or exit 1;
-
- print "\nCreating databases with names covering most ASCII bytes\n\n";
- generate_db("\\\"\\", 1, 45, "\\\\\"\\\\\\");
- generate_db('', 46, 90, '');
- generate_db('', 91, 127, '');
-
- print "\nSetting up data for upgrading\n\n";
- installcheck();
-
- # now we can chdir into the source dir
- chdir "$topdir/src/bin/pg_upgrade";
- print "\nDumping old cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump1.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping old cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- $ENV{PGDATA} = "$data";
- print "\nSetting up new cluster\n\n";
- standard_initdb() or exit 1;
- print "\nRunning pg_upgrade\n\n";
- @args = (
- 'pg_upgrade', '-d', "$data.old", '-D', $data, '-b',
- $bindir, '-B', $bindir);
- system(@args) == 0 or exit 1;
- print "\nStarting new cluster\n\n";
- @args = ('pg_ctl', '-l', "$logdir/postmaster2.log", 'start');
- system(@args) == 0 or exit 1;
- print "\nSetting up stats on new cluster\n\n";
- system(".\\analyze_new_cluster.bat") == 0 or exit 1;
- print "\nDumping new cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump2.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping new cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- print "\nDeleting old cluster\n\n";
- system(".\\delete_old_cluster.bat") == 0 or exit 1;
- print "\nComparing old and new cluster dumps\n\n";
-
- @args = ('diff', '-q', "$tmp_root/dump1.sql", "$tmp_root/dump2.sql");
- system(@args);
- $status = $?;
- if (!$status)
- {
- print "PASSED\n";
- }
- else
- {
- print "dumps not identical!\n";
- exit(1);
- }
-}
-
sub fetchRegressOpts
{
my $handle;
@@ -636,7 +515,6 @@ sub usage
" plcheck run tests of PL languages\n",
" recoverycheck run recovery test suite\n",
" taptest run an arbitrary TAP test set\n",
- " upgradecheck run tests of pg_upgrade\n",
"\nOptions for <arg>: (used by check and installcheck)\n",
" serial serial mode\n",
" parallel parallel mode\n",
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-07 02:14 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 04:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 09:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Alvaro Herrera <[email protected]>
2017-09-19 11:37 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-09-19 22:57 ` Peter Eisentraut <[email protected]>
2017-09-19 23:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Peter Eisentraut @ 2017-09-19 22:57 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Alvaro Herrera <[email protected]>; +Cc: pgsql-hackers
On 9/19/17 07:37, Michael Paquier wrote:
>>> This patch is logged as "waiting on author" in the current commit
>>> fest, but any new patch will depend on the feedback that any other
>>> hacker has to offer based on the set of ideas I have posted upthread.
>>> Hence I am yet unsure what is the correct way to move things forward.
>>> So, any opinions? Peter or others?
>>
>> I think the first step is to send the rebased version of the patch. It
>> was last posted in April ...
>
> Here you go. I have not done anything fancy for cross-version tests yet.
To get things rolling, I have committed just the basic TAP tests, to
give it a spin on the build farm. I'll work through the rest in the
coming days.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-07 02:14 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 04:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 09:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Alvaro Herrera <[email protected]>
2017-09-19 11:37 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 22:57 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
@ 2017-09-19 23:00 ` Michael Paquier <[email protected]>
2017-09-22 20:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-09-19 23:00 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; pgsql-hackers
On Wed, Sep 20, 2017 at 7:57 AM, Peter Eisentraut
<[email protected]> wrote:
> To get things rolling, I have committed just the basic TAP tests, to
> give it a spin on the build farm. I'll work through the rest in the
> coming days.
Thanks!
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-07 02:14 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 04:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 09:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Alvaro Herrera <[email protected]>
2017-09-19 11:37 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 22:57 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-19 23:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-09-22 20:48 ` Peter Eisentraut <[email protected]>
2017-09-29 13:04 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Peter Eisentraut @ 2017-09-22 20:48 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; pgsql-hackers
On 9/19/17 19:00, Michael Paquier wrote:
> On Wed, Sep 20, 2017 at 7:57 AM, Peter Eisentraut
> <[email protected]> wrote:
>> To get things rolling, I have committed just the basic TAP tests, to
>> give it a spin on the build farm. I'll work through the rest in the
>> coming days.
I have reverted this because of the build farm issue. Putting the patch
on hold in the CF until we have a new plan.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Craig Ringer <[email protected]>
2017-04-03 15:12 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 22:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 22:38 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 23:51 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-04 12:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 02:28 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:24 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 22:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-14 06:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-06 13:05 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-07 02:14 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 04:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 09:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Alvaro Herrera <[email protected]>
2017-09-19 11:37 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-19 22:57 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-09-19 23:00 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-09-22 20:48 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
@ 2017-09-29 13:04 ` Peter Eisentraut <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Peter Eisentraut @ 2017-09-29 13:04 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; pgsql-hackers
On 9/22/17 16:48, Peter Eisentraut wrote:
> On 9/19/17 19:00, Michael Paquier wrote:
>> On Wed, Sep 20, 2017 at 7:57 AM, Peter Eisentraut
>> <[email protected]> wrote:
>>> To get things rolling, I have committed just the basic TAP tests, to
>>> give it a spin on the build farm. I'll work through the rest in the
>>> coming days.
>
> I have reverted this because of the build farm issue. Putting the patch
> on hold in the CF until we have a new plan.
Set to "Returned with feedback" now.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-04-03 15:22 ` Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-03 15:34 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
1 sibling, 2 replies; 118+ messages in thread
From: Peter Eisentraut @ 2017-04-03 15:22 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; pgsql-hackers; +Cc: Noah Misch <[email protected]>
On 4/3/17 09:07, Michael Paquier wrote:
> I had for some time a WIP patch on which dust has accumulated, so
> attached is a more polished version. In more details, here is what
> happens:
> - test.sh is removed.
> - vcregress.pl loses upgradecheck.
> - The new test is added. In the case of MSVC this is now part of bincheck.
> Patch has been tested on macos and Windows.
This is a useful start. What I'd really like to see is that instead of
running the full serial tests to populate the pre-upgrade database, we
determine a useful subset of what that ends up generating and just
populate with that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
@ 2017-04-03 15:32 ` Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Andres Freund @ 2017-04-03 15:32 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
On 2017-04-03 11:22:02 -0400, Peter Eisentraut wrote:
> On 4/3/17 09:07, Michael Paquier wrote:
> > I had for some time a WIP patch on which dust has accumulated, so
> > attached is a more polished version. In more details, here is what
> > happens:
> > - test.sh is removed.
> > - vcregress.pl loses upgradecheck.
> > - The new test is added. In the case of MSVC this is now part of bincheck.
> > Patch has been tested on macos and Windows.
>
> This is a useful start. What I'd really like to see is that instead of
> running the full serial tests to populate the pre-upgrade database, we
> determine a useful subset of what that ends up generating and just
> populate with that.
That doesn't strike as particularly future proof. We intentionally
leave objects behind pg_regress runs, but that only works if we actually
run them...
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
@ 2017-04-04 13:52 ` Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Peter Eisentraut @ 2017-04-04 13:52 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
On 4/3/17 11:32, Andres Freund wrote:
> That doesn't strike as particularly future proof. We intentionally
> leave objects behind pg_regress runs, but that only works if we actually
> run them...
I generally agree with the sentiments expressed later in this thread.
But just to clarify what I meant here: We don't need to run a, say,
1-minute serial test to load a few "left behind" objects for the
pg_upgrade test, if we can load the same set of objects using dedicated
scripting in say 2 seconds. This would make both the pg_upgrade tests
faster and would reduce the hidden dependencies in the main tests about
which kinds of objects need to be left behind.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
@ 2017-04-05 02:30 ` Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2017-04-05 02:30 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Andres Freund <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
On Tue, Apr 4, 2017 at 10:52 PM, Peter Eisentraut
<[email protected]> wrote:
> On 4/3/17 11:32, Andres Freund wrote:
>> That doesn't strike as particularly future proof. We intentionally
>> leave objects behind pg_regress runs, but that only works if we actually
>> run them...
>
> I generally agree with the sentiments expressed later in this thread.
> But just to clarify what I meant here: We don't need to run a, say,
> 1-minute serial test to load a few "left behind" objects for the
> pg_upgrade test, if we can load the same set of objects using dedicated
> scripting in say 2 seconds. This would make both the pg_upgrade tests
> faster and would reduce the hidden dependencies in the main tests about
> which kinds of objects need to be left behind.
Making the tests run shorter while maintaining the current code
coverage is nice. But this makes more complicated the test suite
maintenance as this needs either a dedicated regression schedule or an
extra test suite where objects are created just for the sake of
pg_upgrade. This increases the risks of getting a rotten test suite
with the time if patch makers and reviewers are not careful.
--
Michael
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
@ 2017-04-05 13:52 ` Stephen Frost <[email protected]>
2017-04-05 14:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Stephen Frost @ 2017-04-05 13:52 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Michael,
* Michael Paquier ([email protected]) wrote:
> On Tue, Apr 4, 2017 at 10:52 PM, Peter Eisentraut
> <[email protected]> wrote:
> > On 4/3/17 11:32, Andres Freund wrote:
> >> That doesn't strike as particularly future proof. We intentionally
> >> leave objects behind pg_regress runs, but that only works if we actually
> >> run them...
> >
> > I generally agree with the sentiments expressed later in this thread.
> > But just to clarify what I meant here: We don't need to run a, say,
> > 1-minute serial test to load a few "left behind" objects for the
> > pg_upgrade test, if we can load the same set of objects using dedicated
> > scripting in say 2 seconds. This would make both the pg_upgrade tests
> > faster and would reduce the hidden dependencies in the main tests about
> > which kinds of objects need to be left behind.
>
> Making the tests run shorter while maintaining the current code
> coverage is nice. But this makes more complicated the test suite
> maintenance as this needs either a dedicated regression schedule or an
> extra test suite where objects are created just for the sake of
> pg_upgrade. This increases the risks of getting a rotten test suite
> with the time if patch makers and reviewers are not careful.
I believe that what Peter was getting at is that the pg_dump TAP tests
create a whole slew of objects in just a few seconds and are able to
then exercise those code-paths in pg_dump, without needing to run the
entire serial regression test run.
I'm still not completely convinced that we actually need to
independently test pg_upgrade by creating all the objects which the
pg_dump TAP tests do, given that pg_upgrade just runs pg_dump
underneath. If we really want to do that, however, what we should do is
abstract out the pg_dump set of tests into a place that both the pg_dump
and pg_upgrade TAP tests could use them to create all the types of
objects which are supported to perform their tests.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-05 14:15 ` Tom Lane <[email protected]>
2017-04-05 14:40 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Tom Lane @ 2017-04-05 14:15 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Stephen Frost <[email protected]> writes:
> I believe that what Peter was getting at is that the pg_dump TAP tests
> create a whole slew of objects in just a few seconds and are able to
> then exercise those code-paths in pg_dump, without needing to run the
> entire serial regression test run.
Right. But there's a certain amount of serendipity involved in using the
core regression tests' final results. For example, I don't know how long
it would've taken us to understand the problems around dumping and
reloading child tables with inconsistent column orders, had there not been
examples of that in the regression tests. I worry that creating a sterile
set of objects for testing pg_dump will leave blind spots, because it will
mean that we only test cases that we explicitly created test cases for.
> I'm still not completely convinced that we actually need to
> independently test pg_upgrade by creating all the objects which the
> pg_dump TAP tests do, given that pg_upgrade just runs pg_dump
> underneath. If we really want to do that, however, what we should do is
> abstract out the pg_dump set of tests into a place that both the pg_dump
> and pg_upgrade TAP tests could use them to create all the types of
> objects which are supported to perform their tests.
I think it's largely pointless to test pg_dump --binary-upgrade except
as a part of pg_upgrade.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
@ 2017-04-05 14:40 ` Stephen Frost <[email protected]>
2017-04-05 14:45 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-05 15:02 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
0 siblings, 2 replies; 118+ messages in thread
From: Stephen Frost @ 2017-04-05 14:40 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Tom,
* Tom Lane ([email protected]) wrote:
> Stephen Frost <[email protected]> writes:
> > I believe that what Peter was getting at is that the pg_dump TAP tests
> > create a whole slew of objects in just a few seconds and are able to
> > then exercise those code-paths in pg_dump, without needing to run the
> > entire serial regression test run.
>
> Right. But there's a certain amount of serendipity involved in using the
> core regression tests' final results. For example, I don't know how long
> it would've taken us to understand the problems around dumping and
> reloading child tables with inconsistent column orders, had there not been
> examples of that in the regression tests. I worry that creating a sterile
> set of objects for testing pg_dump will leave blind spots, because it will
> mean that we only test cases that we explicitly created test cases for.
We don't need to only create sterile sets of objects in the pg_dump TAP
tests. I don't believe we need to populate GIN indexes or vacuum them
to test pg_dump/pg_upgrade either (at least, not if we're going to stick
to the pg_upgrade test basically being if pg_dump returns the same
results before-and-after).
I'm all for adding tests into pg_dump which do things like drop columns
and change column names and other cases which could impact if the
pg_dump is correct or not, and there's nothing preventing those tests
from being added in the existing structure. Certainly, before we remove
the coverage provided by running the serial test suite and then using
pg_upgrade, we should analyze what is being tested and ensure that we're
providing that same set of testing in the pg_dump TAP tests.
> > I'm still not completely convinced that we actually need to
> > independently test pg_upgrade by creating all the objects which the
> > pg_dump TAP tests do, given that pg_upgrade just runs pg_dump
> > underneath. If we really want to do that, however, what we should do is
> > abstract out the pg_dump set of tests into a place that both the pg_dump
> > and pg_upgrade TAP tests could use them to create all the types of
> > objects which are supported to perform their tests.
>
> I think it's largely pointless to test pg_dump --binary-upgrade except
> as a part of pg_upgrade.
That's how I discovered that comments and security labels weren't being
pulled through to the new cluster for blobs, so I would have to disagree
with this. Frankly, it's also much more straight-forward to run
pg_dump --binary-upgrade than it is to get pg_upgrade to do the same.
Still, I'm not actually against centralizing the tests done with pg_dump
such that they could be used by pg_upgrade also. Creating all those
objects takes less than a second, at least on my system, so it would
still be quite a bit faster than running the serial regression suite.
We might also consider if there's a way to change the format for those
tests to make them a bit less impenetrable for non-Perl folks to work
with and to make it simpler to add new tests as new features are added.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
2017-04-05 14:40 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-05 14:45 ` Andres Freund <[email protected]>
2017-04-05 14:50 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Andres Freund @ 2017-04-05 14:45 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Hi,
On 2017-04-05 10:40:41 -0400, Stephen Frost wrote:
> * Tom Lane ([email protected]) wrote:
> > Stephen Frost <[email protected]> writes:
> > > I believe that what Peter was getting at is that the pg_dump TAP tests
> > > create a whole slew of objects in just a few seconds and are able to
> > > then exercise those code-paths in pg_dump, without needing to run the
> > > entire serial regression test run.
> >
> > Right. But there's a certain amount of serendipity involved in using the
> > core regression tests' final results. For example, I don't know how long
> > it would've taken us to understand the problems around dumping and
> > reloading child tables with inconsistent column orders, had there not been
> > examples of that in the regression tests. I worry that creating a sterile
> > set of objects for testing pg_dump will leave blind spots, because it will
> > mean that we only test cases that we explicitly created test cases for.
>
> We don't need to only create sterile sets of objects in the pg_dump TAP
> tests.
I really, really don't understand why we're conflating making pg_upgrade
tests less fragile / duplicative with changing what we use to test it.
This seems to have the sole result that we're not going to get anywhere.
> I don't believe we need to populate GIN indexes or vacuum them
> to test pg_dump/pg_upgrade either (at least, not if we're going to stick
> to the pg_upgrade test basically being if pg_dump returns the same
> results before-and-after).
I think we *should* have populated GIN indexes. Yes, the coverage isn't
perfect, but the VACUUM definitely gives a decent amount of coverage
whether the gin index looks halfway sane after the upgrade.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
2017-04-05 14:40 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:45 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
@ 2017-04-05 14:50 ` Stephen Frost <[email protected]>
2017-04-05 15:01 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Stephen Frost @ 2017-04-05 14:50 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Andres,
* Andres Freund ([email protected]) wrote:
> On 2017-04-05 10:40:41 -0400, Stephen Frost wrote:
> > * Tom Lane ([email protected]) wrote:
> > > Stephen Frost <[email protected]> writes:
> > > > I believe that what Peter was getting at is that the pg_dump TAP tests
> > > > create a whole slew of objects in just a few seconds and are able to
> > > > then exercise those code-paths in pg_dump, without needing to run the
> > > > entire serial regression test run.
> > >
> > > Right. But there's a certain amount of serendipity involved in using the
> > > core regression tests' final results. For example, I don't know how long
> > > it would've taken us to understand the problems around dumping and
> > > reloading child tables with inconsistent column orders, had there not been
> > > examples of that in the regression tests. I worry that creating a sterile
> > > set of objects for testing pg_dump will leave blind spots, because it will
> > > mean that we only test cases that we explicitly created test cases for.
> >
> > We don't need to only create sterile sets of objects in the pg_dump TAP
> > tests.
>
> I really, really don't understand why we're conflating making pg_upgrade
> tests less fragile / duplicative with changing what we use to test it.
> This seems to have the sole result that we're not going to get anywhere.
Probably because the point was brought up that the regression tests for
pg_upgrade spend a bunch of time doing something which, ultimately,
don't actually add any real value. Yes, there are bits of the core
regression tests that currently add value over what we have through
other approaches, but that's not where the bulk of running those tests
go.
> > I don't believe we need to populate GIN indexes or vacuum them
> > to test pg_dump/pg_upgrade either (at least, not if we're going to stick
> > to the pg_upgrade test basically being if pg_dump returns the same
> > results before-and-after).
>
> I think we *should* have populated GIN indexes. Yes, the coverage isn't
> perfect, but the VACUUM definitely gives a decent amount of coverage
> whether the gin index looks halfway sane after the upgrade.
We don't look at the gin index after the upgrade in the current
pg_upgrade testing, so I don't see why you feel it's at all valuable.
If we *did* do that (and I'm all for adding such tests), then perhaps
this argument would make sense, but we don't today and I haven't seen
anyone propose changing that.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
2017-04-05 14:40 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:45 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-05 14:50 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-05 15:01 ` Andres Freund <[email protected]>
2017-04-05 15:07 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andres Freund @ 2017-04-05 15:01 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
On 2017-04-05 10:50:19 -0400, Stephen Frost wrote:
> Andres,
>
> * Andres Freund ([email protected]) wrote:
> > On 2017-04-05 10:40:41 -0400, Stephen Frost wrote:
> > > * Tom Lane ([email protected]) wrote:
> > > > Stephen Frost <[email protected]> writes:
> > > > > I believe that what Peter was getting at is that the pg_dump TAP tests
> > > > > create a whole slew of objects in just a few seconds and are able to
> > > > > then exercise those code-paths in pg_dump, without needing to run the
> > > > > entire serial regression test run.
> > > >
> > > > Right. But there's a certain amount of serendipity involved in using the
> > > > core regression tests' final results. For example, I don't know how long
> > > > it would've taken us to understand the problems around dumping and
> > > > reloading child tables with inconsistent column orders, had there not been
> > > > examples of that in the regression tests. I worry that creating a sterile
> > > > set of objects for testing pg_dump will leave blind spots, because it will
> > > > mean that we only test cases that we explicitly created test cases for.
> > >
> > > We don't need to only create sterile sets of objects in the pg_dump TAP
> > > tests.
> >
> > I really, really don't understand why we're conflating making pg_upgrade
> > tests less fragile / duplicative with changing what we use to test it.
> > This seems to have the sole result that we're not going to get anywhere.
>
> Probably because the point was brought up that the regression tests for
> pg_upgrade spend a bunch of time doing something which, ultimately,
> don't actually add any real value. Yes, there are bits of the core
> regression tests that currently add value over what we have through
> other approaches, but that's not where the bulk of running those tests
> go.
Create a separate patch [& thread] about that, don't conflate the
topics. I'm very much in favor of this rewrite, I'm very much not in
favor of only using some targeted testsuite. By combining two
independent changes, you're just making it less likely that anything
happens.
> > > I don't believe we need to populate GIN indexes or vacuum them
> > > to test pg_dump/pg_upgrade either (at least, not if we're going to stick
> > > to the pg_upgrade test basically being if pg_dump returns the same
> > > results before-and-after).
> >
> > I think we *should* have populated GIN indexes. Yes, the coverage isn't
> > perfect, but the VACUUM definitely gives a decent amount of coverage
> > whether the gin index looks halfway sane after the upgrade.
>
> We don't look at the gin index after the upgrade in the current
> pg_upgrade testing, so I don't see why you feel it's at all valuable.
It's be trivial to add a VACUUM to the point where analyze_new_cluster
is currently run. And I've previously run more manual tests. Is that
perfect - no, definitely not.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
2017-04-05 14:40 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:45 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-05 14:50 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 15:01 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
@ 2017-04-05 15:07 ` Stephen Frost <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Stephen Frost @ 2017-04-05 15:07 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Andres,
* Andres Freund ([email protected]) wrote:
> On 2017-04-05 10:50:19 -0400, Stephen Frost wrote:
> > Probably because the point was brought up that the regression tests for
> > pg_upgrade spend a bunch of time doing something which, ultimately,
> > don't actually add any real value. Yes, there are bits of the core
> > regression tests that currently add value over what we have through
> > other approaches, but that's not where the bulk of running those tests
> > go.
>
> Create a separate patch [& thread] about that, don't conflate the
> topics. I'm very much in favor of this rewrite, I'm very much not in
> favor of only using some targeted testsuite. By combining two
> independent changes, you're just making it less likely that anything
> happens.
I've made it clear, I thought, a couple of times that I agree with the
rewrite and that we should move forward with it. Nothing on this
sub-thread changes that. It's also registered in the 2017-07
commitfest, so I wouldn't think that there's a risk of it being
forgotten or that we need to cut off all discussion about what may
change between now and July that would be relevant to this patch.
> > We don't look at the gin index after the upgrade in the current
> > pg_upgrade testing, so I don't see why you feel it's at all valuable.
>
> It's be trivial to add a VACUUM to the point where analyze_new_cluster
> is currently run. And I've previously run more manual tests. Is that
> perfect - no, definitely not.
Being trivial doesn't mean it's something we're actually doing today.
Given that we aren't actually changing anything in the index during a
same-version pg_upgrade, nor are we changing the code that's run by
that VACUUM, I'm curious just what we're ending up testing that's
different from just restarting the existing cluster and running a new
VACUUM.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
2017-04-05 14:40 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-05 15:02 ` Tom Lane <[email protected]>
2017-04-05 15:13 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Tom Lane @ 2017-04-05 15:02 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Stephen Frost <[email protected]> writes:
> * Tom Lane ([email protected]) wrote:
>> Right. But there's a certain amount of serendipity involved in using the
>> core regression tests' final results. For example, I don't know how long
>> it would've taken us to understand the problems around dumping and
>> reloading child tables with inconsistent column orders, had there not been
>> examples of that in the regression tests. I worry that creating a sterile
>> set of objects for testing pg_dump will leave blind spots, because it will
>> mean that we only test cases that we explicitly created test cases for.
> I'm all for adding tests into pg_dump which do things like drop columns
> and change column names and other cases which could impact if the
> pg_dump is correct or not, and there's nothing preventing those tests
> from being added in the existing structure. Certainly, before we remove
> the coverage provided by running the serial test suite and then using
> pg_upgrade, we should analyze what is being tested and ensure that we're
> providing that same set of testing in the pg_dump TAP tests.
I don't think you grasped my basic point, which is that I'm worried about
emergent cases that we don't foresee needing to test (and that no amount
of code coverage checking would have shown up as being overlooked).
Admittedly, relying on the core regression tests to trigger such cases is
a pretty haphazard strategy, but it's way better than no strategy at all.
> We might also consider if there's a way to change the format for those
> tests to make them a bit less impenetrable for non-Perl folks to work
> with and to make it simpler to add new tests as new features are added.
TBH, that's part of my allergy to this concept, ie that this test
mechanism seems pretty write-only. I do not think that people will add
pg_dump test cases except when required to by project policy, so that
we will end up with a very skeletal set of tests that won't find any
unforeseen behaviors.
The TAP tests in general are utterly developer-unfriendly from where
I sit: not only is the code pretty unreadable, but god help you when
you need to try to debug a failure. I think that some serious effort
needs to be spent on improving that situation before we imagine that
we can throw away other test mechanisms we have today in favor of
TAP tests.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
2017-04-05 14:40 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 15:02 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
@ 2017-04-05 15:13 ` Stephen Frost <[email protected]>
2017-04-06 01:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Noah Misch <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Stephen Frost @ 2017-04-05 15:13 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Tom,
* Tom Lane ([email protected]) wrote:
> Stephen Frost <[email protected]> writes:
> > I'm all for adding tests into pg_dump which do things like drop columns
> > and change column names and other cases which could impact if the
> > pg_dump is correct or not, and there's nothing preventing those tests
> > from being added in the existing structure. Certainly, before we remove
> > the coverage provided by running the serial test suite and then using
> > pg_upgrade, we should analyze what is being tested and ensure that we're
> > providing that same set of testing in the pg_dump TAP tests.
>
> I don't think you grasped my basic point, which is that I'm worried about
> emergent cases that we don't foresee needing to test (and that no amount
> of code coverage checking would have shown up as being overlooked).
> Admittedly, relying on the core regression tests to trigger such cases is
> a pretty haphazard strategy, but it's way better than no strategy at all.
The tests that were added to the core regression suite were done so for
a reason and hopefully we can identify cases where it'd make sense to
also run those tests for pg_upgrade/pg_dump testing. More-or-less
anything that materially changes the catalog should be included, I would
think. Things that are only really only working with the heap/index
files don't really need to be performed because the pg_upgrade process
doesn't change those.
> > We might also consider if there's a way to change the format for those
> > tests to make them a bit less impenetrable for non-Perl folks to work
> > with and to make it simpler to add new tests as new features are added.
>
> TBH, that's part of my allergy to this concept, ie that this test
> mechanism seems pretty write-only. I do not think that people will add
> pg_dump test cases except when required to by project policy, so that
> we will end up with a very skeletal set of tests that won't find any
> unforeseen behaviors.
I certainly agree that the current structure for the tests isn't trivial
to work with and would welcome suggestions as to how to improve it. Now
that we've had this testing structure for a year and have added quite a
bit more to it, it's definitely clear that we need to find a more
developer-friendly approach.
> The TAP tests in general are utterly developer-unfriendly from where
> I sit: not only is the code pretty unreadable, but god help you when
> you need to try to debug a failure. I think that some serious effort
> needs to be spent on improving that situation before we imagine that
> we can throw away other test mechanisms we have today in favor of
> TAP tests.
Agreed.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
2017-04-04 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Re: Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-05 13:52 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 14:15 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
2017-04-05 14:40 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-05 15:02 ` Re: Rewriting the test of pg_upgrade as a TAP test Tom Lane <[email protected]>
2017-04-05 15:13 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-06 01:30 ` Noah Misch <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Noah Misch @ 2017-04-06 01:30 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Tom Lane <[email protected]>; Michael Paquier <[email protected]>; Peter Eisentraut <[email protected]>; Andres Freund <[email protected]>; pgsql-hackers
On Wed, Apr 05, 2017 at 11:13:33AM -0400, Stephen Frost wrote:
> * Tom Lane ([email protected]) wrote:
> > Stephen Frost <[email protected]> writes:
> > > I'm all for adding tests into pg_dump which do things like drop columns
> > > and change column names and other cases which could impact if the
> > > pg_dump is correct or not, and there's nothing preventing those tests
> > > from being added in the existing structure. Certainly, before we remove
> > > the coverage provided by running the serial test suite and then using
> > > pg_upgrade, we should analyze what is being tested and ensure that we're
> > > providing that same set of testing in the pg_dump TAP tests.
> >
> > I don't think you grasped my basic point, which is that I'm worried about
> > emergent cases that we don't foresee needing to test (and that no amount
> > of code coverage checking would have shown up as being overlooked).
> > Admittedly, relying on the core regression tests to trigger such cases is
> > a pretty haphazard strategy, but it's way better than no strategy at all.
>
> The tests that were added to the core regression suite were done so for
> a reason and hopefully we can identify cases where it'd make sense to
> also run those tests for pg_upgrade/pg_dump testing.
I think you _are_ missing Tom's point. We've caught pg_dump and pg_upgrade
bugs thanks to regression database objects created for purposes unrelated to
pg_dump. It's true that there exist other test strategies that are more
efficient or catch more bugs overall. None of them substitute 100% for the
serendipity seen in testing dump/restore on the regression database.
> More-or-less
> anything that materially changes the catalog should be included, I would
> think. Things that are only really only working with the heap/index
> files don't really need to be performed because the pg_upgrade process
> doesn't change those.
That is formally true.
Also, I agree with Andres that this is not a thread for discussing test
changes beyond mechanical translation of the pg_upgrade test suite.
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
@ 2017-04-03 15:34 ` Stephen Frost <[email protected]>
2017-04-03 17:43 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Stephen Frost @ 2017-04-03 15:34 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Peter,
* Peter Eisentraut ([email protected]) wrote:
> On 4/3/17 09:07, Michael Paquier wrote:
> > I had for some time a WIP patch on which dust has accumulated, so
> > attached is a more polished version. In more details, here is what
> > happens:
> > - test.sh is removed.
> > - vcregress.pl loses upgradecheck.
> > - The new test is added. In the case of MSVC this is now part of bincheck.
> > Patch has been tested on macos and Windows.
>
> This is a useful start. What I'd really like to see is that instead of
> running the full serial tests to populate the pre-upgrade database, we
> determine a useful subset of what that ends up generating and just
> populate with that.
In the past, we've had the notion that the regression tests are intended
to also cover pg_upgrade/pg_dump by "leaving things around". What I
found in my efforts to provide better coverage in pg_dump is that there
was quite a bit of coverage missing using that approach.
Perhaps that could be fixed, but I tend to think it's a better approach
to have a complete set of pg_upgrade/pg_dump tests in one place that
doesn't also have a bunch of other tests mixed in (and would also mean
that the regular regression tests could be 'clean').
I could also see us defining one set of commands to run which create
every type of object in the system that pg_dump understands and then
using that to perform the pg_dump and pg_upgrade tests. Those commands
would have to be annotated with minimum major version and maximum major
version, assuming we're going to use them cross-version, but that should
be reasonably straight-forward to do.
Another question is how much sense it makes to test this logic,
essentially, twice. The testing of pg_dump covers the pg_dump code,
which is what pg_upgrade uses anyway. The pg_upgrade tests really need
to cover the non-pg_dump-related parts, assuming we have appropriate
coverage in the pg_dump tests for the --binary-upgrade mode. Of course,
if we don't, then we should go about fixing that. There are certainly
some tests now but perhaps we need more or need to have improvmenets
made there.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:34 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
@ 2017-04-03 17:43 ` Andres Freund <[email protected]>
2017-04-03 17:55 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andres Freund @ 2017-04-03 17:43 UTC (permalink / raw)
To: Stephen Frost <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
On 2017-04-03 11:34:52 -0400, Stephen Frost wrote:
> Peter,
>
> * Peter Eisentraut ([email protected]) wrote:
> > On 4/3/17 09:07, Michael Paquier wrote:
> > > I had for some time a WIP patch on which dust has accumulated, so
> > > attached is a more polished version. In more details, here is what
> > > happens:
> > > - test.sh is removed.
> > > - vcregress.pl loses upgradecheck.
> > > - The new test is added. In the case of MSVC this is now part of bincheck.
> > > Patch has been tested on macos and Windows.
> >
> > This is a useful start. What I'd really like to see is that instead of
> > running the full serial tests to populate the pre-upgrade database, we
> > determine a useful subset of what that ends up generating and just
> > populate with that.
>
> In the past, we've had the notion that the regression tests are intended
> to also cover pg_upgrade/pg_dump by "leaving things around". What I
> found in my efforts to provide better coverage in pg_dump is that there
> was quite a bit of coverage missing using that approach.
>
> Perhaps that could be fixed, but I tend to think it's a better approach
> to have a complete set of pg_upgrade/pg_dump tests in one place that
> doesn't also have a bunch of other tests mixed in (and would also mean
> that the regular regression tests could be 'clean').
>
> I could also see us defining one set of commands to run which create
> every type of object in the system that pg_dump understands and then
> using that to perform the pg_dump and pg_upgrade tests. Those commands
> would have to be annotated with minimum major version and maximum major
> version, assuming we're going to use them cross-version, but that should
> be reasonably straight-forward to do.
>
> Another question is how much sense it makes to test this logic,
> essentially, twice. The testing of pg_dump covers the pg_dump code,
> which is what pg_upgrade uses anyway. The pg_upgrade tests really need
> to cover the non-pg_dump-related parts, assuming we have appropriate
> coverage in the pg_dump tests for the --binary-upgrade mode. Of course,
> if we don't, then we should go about fixing that. There are certainly
> some tests now but perhaps we need more or need to have improvmenets
> made there.
I don't fundamentally disagree with anything here, but I think it'd be a
serious mistake to link this to the conversion of the pg_upgrade tests
to tap tests.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 15:22 ` Re: Rewriting the test of pg_upgrade as a TAP test Peter Eisentraut <[email protected]>
2017-04-03 15:34 ` Re: Rewriting the test of pg_upgrade as a TAP test Stephen Frost <[email protected]>
2017-04-03 17:43 ` Re: Rewriting the test of pg_upgrade as a TAP test Andres Freund <[email protected]>
@ 2017-04-03 17:55 ` Stephen Frost <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Stephen Frost @ 2017-04-03 17:55 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers; Noah Misch <[email protected]>
Andres,
* Andres Freund ([email protected]) wrote:
> I don't fundamentally disagree with anything here, but I think it'd be a
> serious mistake to link this to the conversion of the pg_upgrade tests
> to tap tests.
I agree that we should move forward with that conversion, regardless of
the rest of this discussion.
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Rewriting the test of pg_upgrade as a TAP test - take two
@ 2018-01-26 08:00 Michael Paquier <[email protected]>
2018-03-02 06:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andres Freund <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
0 siblings, 2 replies; 118+ messages in thread
From: Michael Paquier @ 2018-01-26 08:00 UTC (permalink / raw)
To: pgsql-hackers
Hi all,
As promised on a recent thread, here is a second tentative to switch
pg_upgrade's test.sh into a TAP infrastructure.
This is a continuation of the following thread:
https://www.postgresql.org/message-id/CAB7nPqRdaN1A1YNjxNL9T1jUEWct8ttqq29dNv8W_o37%2Be8wfA%40mail.g...
To begin with, compared to last version, I found and fixed a couple of
bugs, and I also implemented an interface which allows for tests of
pg_upgrade across major versions. The patch set is as follows:
- 0001 refactors PostgresNode.pm so as a node's binary path is
registered when created and can be enforced by the test creating the
node via get_new_node. That's useful for pg_upgrade because we want to
use different binary paths for the node to-be-upgraded and the new one.
This is also useful for test suites willing to work on cross-version
tests.
- 0002 begins the move to a TAP suite by introducing a base set of tests
for pg_upgrade.
- 0003 is the real meat, and removes test.sh in favor of a TAP script
aimed at supporting tests using the same version as well as
cross-version tests.
In order to do that, I have changed a bit the interface used for those
tests. A use can enforce the following variables to run a test using a
past version, while the new version is the one of the tree where the TAP
script is kicked:
export oldsrc=...somewhere/postgresql (old version's source tree)
export oldbindir=...otherversion/bin (old version's installed bin dir)
export oldlibdir=...otherversion/lib (old version's installed lib dir)
make check
That is documented as well in TESTING in the patch. While the patch is
working great when working on the same major version, there is still an
issue I am facing related to the loading of shared libraries in
src/test/regress/ for the old server's version after upgrading it. Even
by tweaking LD_LIBRARY_PATH I could not get the path load. The patch has
been tweaked so as the objects from regression tests that depend on
regress.so, autoinc.so and refint.so are not generated, allowing
pg_upgrade to work, which is definitely wrong. I am sure that I missed
a trick here but it is Friday here ;p
Note also that the diff of the dump still needs to be eyeballed for two
reasons:
- hash index handling is different in v10~, as those exist now in the
dumps taken.
- PostgreSQL origin version string shows up.
We could apply as well some post-filters to allow the test to pass, but
that's one subject I would like to discuss on this thread.
Another topic that I would like to discuss is how this interface is fit
for the buildfarm code. After hacking my stuff, I have looked at the
buildfarm code to notice that things like TestUpgradeXversion.pm do
*not* make use of test.sh, and that what I hacked is much similar to
what the buildfarm code is doing, which is itself roughly a copy of what
test.sh does. Andrew, your feedback would be important here.
So, thoughts?
--
Michael
Attachments:
[text/x-diff] 0001-Refactor-PostgresNode.pm-so-as-nodes-can-use-custom-.patch (8.4K, ../../[email protected]/2-0001-Refactor-PostgresNode.pm-so-as-nodes-can-use-custom-.patch)
download | inline diff:
From 1294bb18426cea5c0764d0d07846fee291502b73 Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email protected]>
Date: Wed, 24 Jan 2018 16:19:53 +0900
Subject: [PATCH 1/3] Refactor PostgresNode.pm so as nodes can use custom
binary path
This is a requirement for having a proper TAP test suite for pg_upgrade
where users have the possibility to manipulate nodes which use different
set of binaries during the upgrade processes.
---
src/test/perl/PostgresNode.pm | 80 +++++++++++++++++++++++++++++++++----------
1 file changed, 62 insertions(+), 18 deletions(-)
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm
index 1d5ac4ee35..c0892fb8a0 100644
--- a/src/test/perl/PostgresNode.pm
+++ b/src/test/perl/PostgresNode.pm
@@ -133,7 +133,7 @@ INIT
=over
-=item PostgresNode::new($class, $name, $pghost, $pgport)
+=item PostgresNode::new($class, $name, $pghost, $pgport, $bindir)
Create a new PostgresNode instance. Does not initdb or start it.
@@ -144,13 +144,14 @@ of finding port numbers, registering instances for cleanup, etc.
sub new
{
- my ($class, $name, $pghost, $pgport) = @_;
+ my ($class, $name, $pghost, $pgport, $bindir) = @_;
my $testname = basename($0);
$testname =~ s/\.[^.]+$//;
my $self = {
_port => $pgport,
_host => $pghost,
_basedir => "$TestLib::tmp_check/t_${testname}_${name}_data",
+ _bindir => $bindir,
_name => $name,
_logfile => "$TestLib::log_path/${testname}_${name}.log" };
@@ -284,6 +285,20 @@ sub data_dir
=pod
+=item $node->bin_dir()
+
+Returns the path to the binary directory used by this node.
+
+=cut
+
+sub bin_dir
+{
+ my ($self) = @_;
+ return $self->{_bindir};
+}
+
+=pod
+
=item $node->archive_dir()
If archiving is enabled, WAL files go here.
@@ -328,6 +343,7 @@ sub info
open my $fh, '>', \$_info or die;
print $fh "Name: " . $self->name . "\n";
print $fh "Data directory: " . $self->data_dir . "\n";
+ print $fh "Binary directory: " . $self->bin_dir . "\n";
print $fh "Backup directory: " . $self->backup_dir . "\n";
print $fh "Archive directory: " . $self->archive_dir . "\n";
print $fh "Connection string: " . $self->connstr . "\n";
@@ -401,6 +417,7 @@ sub init
my ($self, %params) = @_;
my $port = $self->port;
my $pgdata = $self->data_dir;
+ my $bindir = $self->bin_dir;
my $host = $self->host;
$params{allows_streaming} = 0 unless defined $params{allows_streaming};
@@ -409,8 +426,8 @@ sub init
mkdir $self->backup_dir;
mkdir $self->archive_dir;
- TestLib::system_or_bail('initdb', '-D', $pgdata, '-A', 'trust', '-N',
- @{ $params{extra} });
+ TestLib::system_or_bail("$bindir/initdb", '-D', $pgdata, '-A', 'trust',
+ '-N', @{ $params{extra} });
TestLib::system_or_bail($ENV{PG_REGRESS}, '--config-auth', $pgdata);
open my $conf, '>>', "$pgdata/postgresql.conf";
@@ -502,12 +519,13 @@ sub backup
{
my ($self, $backup_name) = @_;
my $backup_path = $self->backup_dir . '/' . $backup_name;
+ my $bindir = $self->bin_dir;
my $port = $self->port;
my $name = $self->name;
print "# Taking pg_basebackup $backup_name from node \"$name\"\n";
- TestLib::system_or_bail('pg_basebackup', '-D', $backup_path, '-p', $port,
- '--no-sync');
+ TestLib::system_or_bail("$bindir/pg_basebackup", '-D', $backup_path,
+ '-p', $port, '--no-sync');
print "# Backup finished\n";
}
@@ -660,11 +678,12 @@ sub start
my ($self) = @_;
my $port = $self->port;
my $pgdata = $self->data_dir;
+ my $bindir = $self->bin_dir;
my $name = $self->name;
BAIL_OUT("node \"$name\" is already running") if defined $self->{_pid};
print("### Starting node \"$name\"\n");
- my $ret = TestLib::system_log('pg_ctl', '-D', $self->data_dir, '-l',
- $self->logfile, 'start');
+ my $ret = TestLib::system_log("$bindir/pg_ctl", '-D', $self->data_dir,
+ '-l', $self->logfile, 'start');
if ($ret != 0)
{
@@ -693,11 +712,13 @@ sub stop
my ($self, $mode) = @_;
my $port = $self->port;
my $pgdata = $self->data_dir;
+ my $bindir = $self->bin_dir;
my $name = $self->name;
$mode = 'fast' unless defined $mode;
return unless defined $self->{_pid};
print "### Stopping node \"$name\" using mode $mode\n";
- TestLib::system_or_bail('pg_ctl', '-D', $pgdata, '-m', $mode, 'stop');
+ TestLib::system_or_bail("$bindir/pg_ctl", '-D', $pgdata, '-m', $mode,
+ 'stop');
$self->_update_pid(0);
}
@@ -714,9 +735,10 @@ sub reload
my ($self) = @_;
my $port = $self->port;
my $pgdata = $self->data_dir;
+ my $bindir = $self->bin_dir;
my $name = $self->name;
print "### Reloading node \"$name\"\n";
- TestLib::system_or_bail('pg_ctl', '-D', $pgdata, 'reload');
+ TestLib::system_or_bail("$bindir/pg_ctl", '-D', $pgdata, 'reload');
}
=pod
@@ -732,10 +754,11 @@ sub restart
my ($self) = @_;
my $port = $self->port;
my $pgdata = $self->data_dir;
+ my $bindir = $self->bin_dir;
my $logfile = $self->logfile;
my $name = $self->name;
print "### Restarting node \"$name\"\n";
- TestLib::system_or_bail('pg_ctl', '-D', $pgdata, '-l', $logfile,
+ TestLib::system_or_bail("$bindir/pg_ctl", '-D', $pgdata, '-l', $logfile,
'restart');
$self->_update_pid(1);
}
@@ -753,10 +776,11 @@ sub promote
my ($self) = @_;
my $port = $self->port;
my $pgdata = $self->data_dir;
+ my $bindir = $self->bin_dir;
my $logfile = $self->logfile;
my $name = $self->name;
print "### Promoting node \"$name\"\n";
- TestLib::system_or_bail('pg_ctl', '-D', $pgdata, '-l', $logfile,
+ TestLib::system_or_bail("$bindir/pg_ctl", '-D', $pgdata, '-l', $logfile,
'promote');
}
@@ -860,13 +884,16 @@ sub _update_pid
=pod
-=item PostgresNode->get_new_node(node_name)
+=item PostgresNode->get_new_node(node_name [, $bindir ])
Build a new object of class C<PostgresNode> (or of a subclass, if you have
one), assigning a free port number. Remembers the node, to prevent its port
number from being reused for another node, and to ensure that it gets
shut down when the test script exits.
+<$bindir> can be optionally defined to enforce from where this node should
+use the set of binaries controlling it in the tests.
+
You should generally use this instead of C<PostgresNode::new(...)>.
For backwards compatibility, it is also exported as a standalone function,
@@ -879,6 +906,7 @@ sub get_new_node
my $class = 'PostgresNode';
$class = shift if 1 < scalar @_;
my $name = shift;
+ my $bindir = shift;
my $found = 0;
my $port = $last_port_assigned;
@@ -921,8 +949,21 @@ sub get_new_node
print "# Found free port $port\n";
+ # Find binary directory for this new node.
+ if (!defined($bindir))
+ {
+ # If caller has not defined the binary directory, find it
+ # from pg_config defined in this environment's PATH.
+ my ($stdout, $stderr);
+ my $result = IPC::Run::run [ 'pg_config', '--bindir' ], '>',
+ \$stdout, '2>', \$stderr
+ or die "could not execute pg_config";
+ chomp($stdout);
+ $bindir = $stdout;
+ }
+
# Lock port number found by creating a new node
- my $node = $class->new($name, $test_pghost, $port);
+ my $node = $class->new($name, $test_pghost, $port, $bindir);
# Add node to list of nodes
push(@all_nodes, $node);
@@ -1127,10 +1168,11 @@ sub psql
my $stdout = $params{stdout};
my $stderr = $params{stderr};
+ my $bindir = $self->bin_dir;
my $timeout = undef;
my $timeout_exception = 'psql timed out';
my @psql_params =
- ('psql', '-XAtq', '-d', $self->connstr($dbname), '-f', '-');
+ ("$bindir/psql", '-XAtq', '-d', $self->connstr($dbname), '-f', '-');
# If the caller wants an array and hasn't passed stdout/stderr
# references, allocate temporary ones to capture them so we
@@ -1275,8 +1317,9 @@ sub poll_query_until
my ($self, $dbname, $query, $expected) = @_;
$expected = 't' unless defined($expected); # default value
-
- my $cmd = [ 'psql', '-XAt', '-c', $query, '-d', $self->connstr($dbname) ];
+ my $bindir = $self->bin_dir;
+ my $cmd = [ "$bindir/psql", '-XAt', '-c', $query, '-d',
+ $self->connstr($dbname) ];
my ($stdout, $stderr);
my $max_attempts = 180 * 10;
my $attempts = 0;
@@ -1666,8 +1709,9 @@ sub pg_recvlogical_upto
die 'slot name must be specified' unless defined($slot_name);
die 'endpos must be specified' unless defined($endpos);
+ my $bindir = $self->bin_dir;
my @cmd = (
- 'pg_recvlogical', '-S', $slot_name, '--dbname',
+ "$bindir/pg_recvlogical", '-S', $slot_name, '--dbname',
$self->connstr($dbname));
push @cmd, '--endpos', $endpos;
push @cmd, '-f', '-', '--no-loop', '--start';
--
2.15.1
[text/x-diff] 0002-Add-basic-TAP-test-setup-for-pg_upgrade.patch (1.7K, ../../[email protected]/3-0002-Add-basic-TAP-test-setup-for-pg_upgrade.patch)
download | inline diff:
From df74a70b886bb998ac37195b4d3067c41a012738 Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email protected]>
Date: Wed, 24 Jan 2018 16:22:00 +0900
Subject: [PATCH 2/3] Add basic TAP test setup for pg_upgrade
The plan is to convert the current pg_upgrade test to the TAP
framework. This commit just puts a basic TAP test in place so that we
can see how the build farm behaves, since the build farm client has some
special knowledge of the pg_upgrade tests.
---
src/bin/pg_upgrade/Makefile | 7 ++++---
src/bin/pg_upgrade/t/001_basic.pl | 9 +++++++++
2 files changed, 13 insertions(+), 3 deletions(-)
create mode 100644 src/bin/pg_upgrade/t/001_basic.pl
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 1d6ee702c6..e5c98596a1 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -36,8 +36,9 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-check: test.sh all
+check: test.sh
+ $(prove_check)
MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $< --install
-# installcheck is not supported because there's no meaningful way to test
-# pg_upgrade against a single already-running server
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/t/001_basic.pl b/src/bin/pg_upgrade/t/001_basic.pl
new file mode 100644
index 0000000000..605a7f622f
--- /dev/null
+++ b/src/bin/pg_upgrade/t/001_basic.pl
@@ -0,0 +1,9 @@
+use strict;
+use warnings;
+
+use TestLib;
+use Test::More tests => 8;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
--
2.15.1
[text/x-diff] 0003-Replace-pg_upgrade-s-test.sh-by-a-TAP-test.patch (24.4K, ../../[email protected]/4-0003-Replace-pg_upgrade-s-test.sh-by-a-TAP-test.patch)
download | inline diff:
From f903e01bbb65f1e38cd74b01ee99c4526e4c3b7f Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email protected]>
Date: Fri, 26 Jan 2018 16:37:42 +0900
Subject: [PATCH 3/3] Replace pg_upgrade's test.sh by a TAP test
This replacement still allows tests across major versions, though the
interface to reach that has been changed a bit. See TESTING for more
details on the matter.
---
doc/src/sgml/install-windows.sgml | 1 -
src/bin/pg_upgrade/Makefile | 3 +-
src/bin/pg_upgrade/TESTING | 8 +-
src/bin/pg_upgrade/t/002_pg_upgrade.pl | 213 ++++++++++++++++++++++++++
src/bin/pg_upgrade/test.sh | 264 ---------------------------------
src/test/perl/PostgresNode.pm | 7 +-
src/tools/msvc/vcregress.pl | 124 +---------------
7 files changed, 222 insertions(+), 398 deletions(-)
create mode 100644 src/bin/pg_upgrade/t/002_pg_upgrade.pl
delete mode 100644 src/bin/pg_upgrade/test.sh
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 99e9c7b78e..62fc45e517 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -447,7 +447,6 @@ $ENV{CONFIG}="Debug";
<userinput>vcregress isolationcheck</userinput>
<userinput>vcregress bincheck</userinput>
<userinput>vcregress recoverycheck</userinput>
-<userinput>vcregress upgradecheck</userinput>
</screen>
To change the schedule used (default is parallel), append it to the
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index e5c98596a1..bccab1d723 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -36,9 +36,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-check: test.sh
+check:
$(prove_check)
- MAKE=$(MAKE) bindir=$(bindir) libdir=$(libdir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $< --install
installcheck:
$(prove_installcheck)
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
index 6831f679f6..ee45f6a80f 100644
--- a/src/bin/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -9,14 +9,12 @@ 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:
+source tree for the old version as well as this version. 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
+export oldlibdir=...otherversion/lib (old version's installed lib dir)
+make check
In this case, you will have to manually eyeball the resulting dump
diff for version-specific differences, as explained below.
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
new file mode 100644
index 0000000000..f2c45be284
--- /dev/null
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -0,0 +1,213 @@
+# Set of tests for pg_upgrade.
+use strict;
+use warnings;
+use Cwd;
+use Config;
+use File::Basename;
+use File::Copy;
+use IPC::Run;
+use PostgresNode;
+use TestLib;
+use Test::More tests => 4;
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log([ 'createdb', '--port', $node->port, $dbname ]);
+}
+
+my $startdir = getcwd();
+
+# From now on, the test of pg_upgrade consists in setting up an instance
+# on which regression tests are run. This is the source instance used
+# for the upgrade. Then a new, fresh instance is created, and is used
+# as the target instance for the upgrade. Before running an upgrade a
+# logical dump of the old instance is taken, and a second logical dump
+# of the new instance is taken after the upgrade. The upgrade test
+# passes if there are no differences after running pg_upgrade.
+
+# Determine the version set to use depending on what the caller wants.
+# There are a couple of environment variables to scan for:
+# 1) oldsrc, which points to the code tree of the old instance's binaries
+# which gets upgraded.
+# 2) oldbindir, which points to the binaries of the old instance to
+# upgrade.
+# 2) oldlibdir, which points to the libraries of the old instance to
+# upgrade.
+# If the caller has not defined any of them, default values are used,
+# pointing to the source tree where this script is located.
+my $regress_bin = undef;
+my $newsrc = "../../.."; # top of this code repository
+my $newlibdir;
+my $oldsrc = $newsrc;
+my $oldlibdir = undef;
+my $oldbindir = undef;
+my $dlpath = undef;
+
+my ($stdout, $stderr);
+my $result = IPC::Run::run [ 'pg_config', '--libdir' ], '>',
+ \$stdout, '2>', \$stderr
+ or die "could not execute pg_config";
+chomp($stdout);
+$newlibdir = $stdout;
+
+if (!defined($ENV{oldsrc}) &&
+ !defined($ENV{oldlibdir}) &&
+ !defined($ENV{oldbindir}))
+{
+ # No variables defined, so run the test using this version's
+ # tree for both the new and old instances.
+ $regress_bin = $ENV{PG_REGRESS};
+
+ # Calculate this build's old library directory
+ $oldlibdir = $newlibdir;
+
+ # And this build's old binary directory
+ $result = IPC::Run::run [ 'pg_config', '--bindir' ], '>',
+ \$stdout, '2>', \$stderr
+ or die "could not execute pg_config";
+ chomp($stdout);
+ $oldbindir = $stdout;
+
+ # In this case download path is in src/test/regress.
+ $dlpath = ".";
+}
+elsif (defined($ENV{oldsrc}) &&
+ defined($ENV{oldbindir}) &&
+ defined($ENV{oldlibdir}))
+{
+ # A run is wanted on an old version as base.
+ $oldsrc = $ENV{oldsrc};
+ $oldbindir = $ENV{oldbindir};
+ $oldlibdir = $ENV{oldlibdir};
+ # FIXME: this needs better tuning. Using "." or "$oldlibdir/postgresql"
+ # causes the regression tests to pass but pg_upgrade to fail afterwards.
+ $dlpath = "$oldlibdir";
+ $regress_bin = "$oldsrc/src/test/regress/pg_regress";
+}
+else
+{
+ # Not all variables are defined, so leave and die.
+ die "not all variables in oldsrc, oldlibdir and oldbindir are defined";
+}
+
+# Make sure the installed libraries come first in dynamic load paths.
+$ENV{LD_LIBRARY_PATH}="$newlibdir/postgresql";
+$ENV{DYLD_LIBRARY_PATH}="$newlibdir/postgresql";
+
+# Temporary location for dumps taken
+my $tempdir = TestLib::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = get_new_node('old_node', $oldbindir);
+$oldbindir = $oldnode->bin_dir; # could be default value
+$oldnode->init(extra => [ '--locale=C', '--encoding=LATIN1' ],
+ pg_regress => $regress_bin);
+$oldnode->start;
+
+# Creating databases with names covering most ASCII bytes
+generate_db($oldnode, 1, 45);
+generate_db($oldnode, 46, 90);
+generate_db($oldnode, 91, 127);
+
+# Install manually regress.so, this got forgotten in the process.
+copy "$oldsrc/src/test/regress/regress.so",
+ "$oldlibdir/postgresql/regress.so"
+ unless (-e "$oldlibdir/regress.so");
+
+# Run regression tests on the old instance, using the binaries of this
+# instance. At the same time create a tablespace path needed for the
+# tests, similarly to what "make check" creates.
+chdir dirname($regress_bin);
+rmdir "testtablespace";
+mkdir "testtablespace";
+$oldnode->run_log([ "$oldbindir/createdb", '--port', $oldnode->port,
+ 'regression' ]);
+
+$oldnode->command_ok([$regress_bin, '--schedule', './serial_schedule',
+ '--dlpath', "$dlpath", '--bindir', $oldnode->bin_dir,
+ '--use-existing', '--port', $oldnode->port],
+ 'regression test run on old instance');
+
+# Before dumping, get rid of objects not existing in later versions. This
+# depends on the version of the old server used, and matters only if the
+# old and new source paths
+my $oldpgversion;
+($result, $oldpgversion, $stderr) =
+ $oldnode->psql('postgres', qq[SHOW server_version_num;]);
+my $fix_sql;
+if ($newsrc ne $oldsrc)
+{
+ if ($oldpgversion <= 80400)
+ {
+ $fix_sql = "DROP FUNCTION public.myfunc(integer); DROP FUNCTION public.oldstyle_length(integer, text);";
+ }
+ else
+ {
+ $fix_sql = "DROP FUNCTION public.oldstyle_length(integer, text);";
+ }
+ $oldnode->psql('postgres', $fix_sql);
+}
+
+# Take a dump before performing the upgrade as a base comparison. Note
+# that we need to use pg_dumpall from PATH here.
+$oldnode->command_ok(['pg_dumpall', '--no-sync', '--port', $oldnode->port,
+ '-f', "$tempdir/dump1.sql"],
+ 'dump before running pg_upgrade');
+
+# After dumping, update references to the old source tree's regress.so and
+# such.
+if ($newsrc ne $oldsrc)
+{
+ if ($oldpgversion <= 80400)
+ {
+ $fix_sql = "UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%';";
+ }
+ else
+ {
+ $fix_sql = "UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';";
+ }
+ $oldnode->psql('postgres', $fix_sql);
+
+ my $dump_data = slurp_file("$tempdir/dump1.sql");
+ $dump_data =~ s/$oldsrc/$newsrc/g;
+
+ open my $fh, ">", "$tempdir/dump1.sql" or die "could not open dump file";
+ print $fh $dump_data;
+ close $fh;
+}
+
+# Move back to current directory, all logs generated need to be located
+# at the origin.
+chdir $startdir;
+
+# Update the instance.
+$oldnode->stop;
+
+# Initialize a new node for the upgrade.
+my $newnode = get_new_node('new_node');
+$newnode->init(extra => [ '--locale=C', '--encoding=LATIN1' ]);
+
+# Time for the real run.
+chdir "$newsrc/src/test/regress";
+my $newbindir = $newnode->bin_dir;
+command_ok(['pg_upgrade', '-d', $oldnode->data_dir, '-D', $newnode->data_dir,
+ '-b', $oldnode->bin_dir, '-B', $newnode->bin_dir, '-p', $oldnode->port,
+ '-P', $newnode->port], 'run of pg_upgrade for new instance');
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+run_log(['pg_dumpall', '--no-sync', '--port', $newnode->port,
+ '-f', "$tempdir/dump2.sql"]);
+
+# Compare the two dumps, there should be no differences.
+command_ok(['diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql"],
+ 'Old and new dump checks after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index 39983abea1..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,264 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- # To increase coverage of non-standard segment size without
- # increase test runtime, run these tests with a lower setting.
- "$1" -N --wal-segsize 1
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# Establish how the server will listen for connections
-testhost=`uname -s`
-
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PGHOST=localhost
- ;;
- *)
- 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
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=$LISTEN_ADDRESSES -k \"$PGHOST\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-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"
-
- # 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
- SHLIB_PATH=$libdir:$SHLIB_PATH
- export SHLIB_PATH
- 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
- # be outdated or missing. But don't override anything else that's
- # already in EXTRA_REGRESS_OPTS.
- EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$bindir'"
- export EXTRA_REGRESS_OPTS
-fi
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA=$temp_root/data
-PGDATA="$BASE_PGDATA.old"
-export PGDATA
-rm -rf "$BASE_PGDATA" "$PGDATA"
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-# enable echo so the user can see what is being executed
-set -x
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "$dbname1" || createdb_status=$?
-createdb "$dbname2" || createdb_status=$?
-createdb "$dbname3" || createdb_status=$?
-
-if "$MAKE" -C "$oldsrc" installcheck; then
- oldpgversion=`psql -X -A -t -d regression -c "SHOW server_version_num"`
-
- # before dumping, get rid of objects not existing in later versions
- if [ "$newsrc" != "$oldsrc" ]; then
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="DROP FUNCTION public.myfunc(integer); DROP FUNCTION public.oldstyle_length(integer, text);"
- ;;
- *)
- fix_sql="DROP FUNCTION public.oldstyle_length(integer, text);"
- ;;
- esac
- psql -X -d regression -c "$fix_sql;" || psql_fix_sql_status=$?
- fi
-
- pg_dumpall --no-sync -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
-
- if [ "$newsrc" != "$oldsrc" ]; then
- # update references to old source tree's regress.so etc
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%';"
- ;;
- *)
- fix_sql="UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';"
- ;;
- esac
- psql -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA=$BASE_PGDATA
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "${PGDATA}" -b "$oldbindir" -B "$bindir" -p "$PGPORT" -P "$PGPORT"
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-case $testhost in
- MINGW*) cmd /c analyze_new_cluster.bat ;;
- *) sh ./analyze_new_cluster.sh ;;
-esac
-
-pg_dumpall --no-sync -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-# no need to echo commands anymore
-set +x
-echo
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm
index c0892fb8a0..2e957965ba 100644
--- a/src/test/perl/PostgresNode.pm
+++ b/src/test/perl/PostgresNode.pm
@@ -422,13 +422,14 @@ sub init
$params{allows_streaming} = 0 unless defined $params{allows_streaming};
$params{has_archiving} = 0 unless defined $params{has_archiving};
+ $params{pg_regress} = $ENV{PG_REGRESS} unless defined $params{pg_regress};
mkdir $self->backup_dir;
mkdir $self->archive_dir;
TestLib::system_or_bail("$bindir/initdb", '-D', $pgdata, '-A', 'trust',
'-N', @{ $params{extra} });
- TestLib::system_or_bail($ENV{PG_REGRESS}, '--config-auth', $pgdata);
+ TestLib::system_or_bail($params{pg_regress}, '--config-auth', $pgdata);
open my $conf, '>>', "$pgdata/postgresql.conf";
print $conf "\n# Added by PostgresNode.pm\n";
@@ -683,7 +684,7 @@ sub start
BAIL_OUT("node \"$name\" is already running") if defined $self->{_pid};
print("### Starting node \"$name\"\n");
my $ret = TestLib::system_log("$bindir/pg_ctl", '-D', $self->data_dir,
- '-l', $self->logfile, 'start');
+ '-l', $self->logfile, '-w', 'start');
if ($ret != 0)
{
@@ -904,7 +905,7 @@ which can only create objects of class C<PostgresNode>.
sub get_new_node
{
my $class = 'PostgresNode';
- $class = shift if 1 < scalar @_;
+ $class = shift if 2 < scalar @_;
my $name = shift;
my $bindir = shift;
my $found = 0;
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 314f2c37d2..27dc9dd5c5 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -34,7 +34,7 @@ if (-e "src/tools/msvc/buildenv.pl")
my $what = shift || "";
if ($what =~
-/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|upgradecheck|bincheck|recoverycheck|taptest)$/i
+/^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|bincheck|recoverycheck|taptest)$/i
)
{
$what = uc $what;
@@ -83,7 +83,6 @@ my %command = (
ISOLATIONCHECK => \&isolationcheck,
BINCHECK => \&bincheck,
RECOVERYCHECK => \&recoverycheck,
- UPGRADECHECK => \&upgradecheck,
TAPTEST => \&taptest,);
my $proc = $command{$what};
@@ -418,126 +417,6 @@ sub standard_initdb
$ENV{PGDATA}) == 0);
}
-# This is similar to appendShellString(). Perl system(@args) bypasses
-# cmd.exe, so omit the caret escape layer.
-sub quote_system_arg
-{
- my $arg = shift;
-
- # Change N >= 0 backslashes before a double quote to 2N+1 backslashes.
- $arg =~ s/(\\*)"/${\($1 . $1)}\\"/gs;
-
- # Change N >= 1 backslashes at end of argument to 2N backslashes.
- $arg =~ s/(\\+)$/${\($1 . $1)}/gs;
-
- # Wrap the whole thing in unescaped double quotes.
- return "\"$arg\"";
-}
-
-# Generate a database with a name made of a range of ASCII characters, useful
-# for testing pg_upgrade.
-sub generate_db
-{
- my ($prefix, $from_char, $to_char, $suffix) = @_;
-
- my $dbname = $prefix;
- for my $i ($from_char .. $to_char)
- {
- next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
- $dbname = $dbname . sprintf('%c', $i);
- }
- $dbname .= $suffix;
-
- system('createdb', quote_system_arg($dbname));
- my $status = $? >> 8;
- exit $status if $status;
-}
-
-sub upgradecheck
-{
- my $status;
- my $cwd = getcwd();
-
- # Much of this comes from the pg_upgrade test.sh script,
- # but it only covers the --install case, and not the case
- # where the old and new source or bin dirs are different.
- # i.e. only this version to this version check. That's
- # what pg_upgrade's "make check" does.
-
- $ENV{PGHOST} = 'localhost';
- $ENV{PGPORT} ||= 50432;
- my $tmp_root = "$topdir/src/bin/pg_upgrade/tmp_check";
- (mkdir $tmp_root || die $!) unless -d $tmp_root;
- my $upg_tmp_install = "$tmp_root/install"; # unshared temp install
- print "Setting up temp install\n\n";
- Install($upg_tmp_install, "all", $config);
-
- # Install does a chdir, so change back after that
- chdir $cwd;
- my ($bindir, $libdir, $oldsrc, $newsrc) =
- ("$upg_tmp_install/bin", "$upg_tmp_install/lib", $topdir, $topdir);
- $ENV{PATH} = "$bindir;$ENV{PATH}";
- my $data = "$tmp_root/data";
- $ENV{PGDATA} = "$data.old";
- my $logdir = "$topdir/src/bin/pg_upgrade/log";
- (mkdir $logdir || die $!) unless -d $logdir;
- print "\nRunning initdb on old cluster\n\n";
- standard_initdb() or exit 1;
- print "\nStarting old cluster\n\n";
- my @args = ('pg_ctl', 'start', '-l', "$logdir/postmaster1.log");
- system(@args) == 0 or exit 1;
-
- print "\nCreating databases with names covering most ASCII bytes\n\n";
- generate_db("\\\"\\", 1, 45, "\\\\\"\\\\\\");
- generate_db('', 46, 90, '');
- generate_db('', 91, 127, '');
-
- print "\nSetting up data for upgrading\n\n";
- installcheck();
-
- # now we can chdir into the source dir
- chdir "$topdir/src/bin/pg_upgrade";
- print "\nDumping old cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump1.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping old cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- $ENV{PGDATA} = "$data";
- print "\nSetting up new cluster\n\n";
- standard_initdb() or exit 1;
- print "\nRunning pg_upgrade\n\n";
- @args = (
- 'pg_upgrade', '-d', "$data.old", '-D', $data, '-b',
- $bindir, '-B', $bindir);
- system(@args) == 0 or exit 1;
- print "\nStarting new cluster\n\n";
- @args = ('pg_ctl', '-l', "$logdir/postmaster2.log", 'start');
- system(@args) == 0 or exit 1;
- print "\nSetting up stats on new cluster\n\n";
- system(".\\analyze_new_cluster.bat") == 0 or exit 1;
- print "\nDumping new cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump2.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping new cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- print "\nDeleting old cluster\n\n";
- system(".\\delete_old_cluster.bat") == 0 or exit 1;
- print "\nComparing old and new cluster dumps\n\n";
-
- @args = ('diff', '-q', "$tmp_root/dump1.sql", "$tmp_root/dump2.sql");
- system(@args);
- $status = $?;
- if (!$status)
- {
- print "PASSED\n";
- }
- else
- {
- print "dumps not identical!\n";
- exit(1);
- }
-}
-
sub fetchRegressOpts
{
my $handle;
@@ -647,7 +526,6 @@ sub usage
" plcheck run tests of PL languages\n",
" recoverycheck run recovery test suite\n",
" taptest run an arbitrary TAP test set\n",
- " upgradecheck run tests of pg_upgrade\n",
"\nOptions for <arg>: (used by check and installcheck)\n",
" serial serial mode\n",
" parallel parallel mode\n",
--
2.15.1
[application/pgp-signature] signature.asc (833B, ../../[email protected]/5-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
@ 2018-03-02 06:08 ` Andres Freund <[email protected]>
2018-03-02 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-02 13:02 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
1 sibling, 2 replies; 118+ messages in thread
From: Andres Freund @ 2018-03-02 06:08 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: pgsql-hackers; Andrew Dunstan <[email protected]>
Hi,
On 2018-01-26 17:00:26 +0900, Michael Paquier wrote:
> Another topic that I would like to discuss is how this interface is fit
> for the buildfarm code. After hacking my stuff, I have looked at the
> buildfarm code to notice that things like TestUpgradeXversion.pm do
> *not* make use of test.sh, and that what I hacked is much similar to
> what the buildfarm code is doing, which is itself roughly a copy of what
> test.sh does. Andrew, your feedback would be important here.
Andrew, any comments?
> From 1294bb18426cea5c0764d0d07846fee291502b73 Mon Sep 17 00:00:00 2001
> From: Michael Paquier <[email protected]>
> Date: Wed, 24 Jan 2018 16:19:53 +0900
> Subject: [PATCH 1/3] Refactor PostgresNode.pm so as nodes can use custom
> binary path
>
> This is a requirement for having a proper TAP test suite for pg_upgrade
> where users have the possibility to manipulate nodes which use different
> set of binaries during the upgrade processes.
Seems reasonable.
> + # Find binary directory for this new node.
> + if (!defined($bindir))
> + {
> + # If caller has not defined the binary directory, find it
> + # from pg_config defined in this environment's PATH.
> + my ($stdout, $stderr);
> + my $result = IPC::Run::run [ 'pg_config', '--bindir' ], '>',
> + \$stdout, '2>', \$stderr
> + or die "could not execute pg_config";
> + chomp($stdout);
> + $bindir = $stdout;
> + }
> +
This isn't really required, we could just assume things are on PATH if
bindir isn't specified. Don't have strong feelings about it.
> From df74a70b886bb998ac37195b4d3067c41a012738 Mon Sep 17 00:00:00 2001
> From: Michael Paquier <[email protected]>
> Date: Wed, 24 Jan 2018 16:22:00 +0900
> Subject: [PATCH 2/3] Add basic TAP test setup for pg_upgrade
>
> The plan is to convert the current pg_upgrade test to the TAP
> framework. This commit just puts a basic TAP test in place so that we
> can see how the build farm behaves, since the build farm client has some
> special knowledge of the pg_upgrade tests.
Not sure I see the point of keeping this separate, but whatever...
> From f903e01bbb65f1e38cd74b01ee99c4526e4c3b7f Mon Sep 17 00:00:00 2001
> From: Michael Paquier <[email protected]>
> Date: Fri, 26 Jan 2018 16:37:42 +0900
> Subject: [PATCH 3/3] Replace pg_upgrade's test.sh by a TAP test
>
> This replacement still allows tests across major versions, though the
> interface to reach that has been changed a bit. See TESTING for more
> details on the matter.
> +++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
> @@ -0,0 +1,213 @@
> +# Set of tests for pg_upgrade.
> +use strict;
> +use warnings;
> +use Cwd;
> +use Config;
> +use File::Basename;
> +use File::Copy;
> +use IPC::Run;
> +use PostgresNode;
> +use TestLib;
> +use Test::More tests => 4;
> +
> +# Generate a database with a name made of a range of ASCII characters.
> +sub generate_db
> +{
s/_/_random_/?
> +# From now on,
Odd phrasing imo.
>
> +elsif (defined($ENV{oldsrc}) &&
> + defined($ENV{oldbindir}) &&
> + defined($ENV{oldlibdir}))
> +{
> + # A run is wanted on an old version as base.
> + $oldsrc = $ENV{oldsrc};
> + $oldbindir = $ENV{oldbindir};
> + $oldlibdir = $ENV{oldlibdir};
> + # FIXME: this needs better tuning. Using "." or "$oldlibdir/postgresql"
> + # causes the regression tests to pass but pg_upgrade to fail afterwards.
Planning to fix it?
> +# Install manually regress.so, this got forgotten in the process.
> +copy "$oldsrc/src/test/regress/regress.so",
> + "$oldlibdir/postgresql/regress.so"
> + unless (-e "$oldlibdir/regress.so");
Weird comment again.
> +# Run regression tests on the old instance, using the binaries of this
> +# instance. At the same time create a tablespace path needed for the
> +# tests, similarly to what "make check" creates.
What does "using binaries of this instance" mean? And why?
> +chdir dirname($regress_bin);
> +rmdir "testtablespace";
> +mkdir "testtablespace";
> +$oldnode->run_log([ "$oldbindir/createdb", '--port', $oldnode->port,
> + 'regression' ]);
> +$oldnode->command_ok([$regress_bin, '--schedule', './serial_schedule',
> + '--dlpath', "$dlpath", '--bindir', $oldnode->bin_dir,
> + '--use-existing', '--port', $oldnode->port],
> + 'regression test run on old instance');
> +# Before dumping, get rid of objects not existing in later versions. This
> +# depends on the version of the old server used, and matters only if the
> +# old and new source paths
> +my $oldpgversion;
> +($result, $oldpgversion, $stderr) =
> + $oldnode->psql('postgres', qq[SHOW server_version_num;]);
> +my $fix_sql;
> +if ($newsrc ne $oldsrc)
> +{
> + if ($oldpgversion <= 80400)
> + {
> + $fix_sql = "DROP FUNCTION public.myfunc(integer); DROP FUNCTION public.oldstyle_length(integer, text);";
> + }
> + else
> + {
> + $fix_sql = "DROP FUNCTION public.oldstyle_length(integer, text);";
> + }
> + $oldnode->psql('postgres', $fix_sql);
> +}
I know you copied this, but what?
> +# Take a dump before performing the upgrade as a base comparison. Note
> +# that we need to use pg_dumpall from PATH here.
Whe do we need to?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-02 06:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andres Freund <[email protected]>
@ 2018-03-02 08:03 ` Andrew Dunstan <[email protected]>
2018-03-02 13:11 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-02 14:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Alvaro Herrera <[email protected]>
1 sibling, 2 replies; 118+ messages in thread
From: Andrew Dunstan @ 2018-03-02 08:03 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
On Fri, Mar 2, 2018 at 4:38 PM, Andres Freund <[email protected]> wrote:
> Hi,
>
> On 2018-01-26 17:00:26 +0900, Michael Paquier wrote:
>> Another topic that I would like to discuss is how this interface is fit
>> for the buildfarm code. After hacking my stuff, I have looked at the
>> buildfarm code to notice that things like TestUpgradeXversion.pm do
>> *not* make use of test.sh, and that what I hacked is much similar to
>> what the buildfarm code is doing, which is itself roughly a copy of what
>> test.sh does. Andrew, your feedback would be important here.
>
> Andrew, any comments?
>
>
I'll take a look.
Meanwhile:
TestUpgradeXversion.pm is different in a number of respects from the
inbuilt test regime. It doesn't run the normal regression suite to set
up a test. Rather, it saves out the installed binaries and data
directory of the buildfarm client, and then tries to upgrade those
saved data directorories from earlier branches or the current branch
to the target version being tested. It has to make a few adjustments
to the databases along the way. It does a compare of pre- and post-
pg_dumpall runs, allowing a fuzz factor if the versions are different.
The other upside to the scheme is that we're testing pg_dump against
earlier branches as part of testing pg_upgrade.
All this consumes quite a bit of disk space - currently 3.5Gb between
runs on crake. That could probably be reduced some by removing log as
we go.
I don't think a scheme like this is going to be terribly workable
outside some system such as the buildfarm that deals with multiple
branches.
One of the significant pluses to TestUpgradeXversion.pm is that it
tests upgrading quite a bit more than the standard regression
database. It also tests all the contrib databases and the isolation
and pl_regression databases. Several bugs have been found that way,
IIRC, and we should arguably do something along the same lines for our
builtin testing.
I'll post a follow up when I've had a chance to have a good look at
what Michael has actually done.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-02 06:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andres Freund <[email protected]>
2018-03-02 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
@ 2018-03-02 13:11 ` Michael Paquier <[email protected]>
1 sibling, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2018-03-02 13:11 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Andres Freund <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Fri, Mar 02, 2018 at 06:33:55PM +1030, Andrew Dunstan wrote:
> TestUpgradeXversion.pm is different in a number of respects from the
> inbuilt test regime. It doesn't run the normal regression suite to set
> up a test. Rather, it saves out the installed binaries and data
> directory of the buildfarm client, and then tries to upgrade those
> saved data directorories from earlier branches or the current branch
> to the target version being tested. It has to make a few adjustments
> to the databases along the way. It does a compare of pre- and post-
> pg_dumpall runs, allowing a fuzz factor if the versions are different.
> The other upside to the scheme is that we're testing pg_dump against
> earlier branches as part of testing pg_upgrade.
Thanks for the details. test.sh also does a comparison of the output
of pg_dumpall between the instance before and after upgrade. The
adjustments done are also close to what test.sh does, and what my patch
does. This consists in update prosrc for defined functions (+alpha),
right?
> I don't think a scheme like this is going to be terribly workable
> outside some system such as the buildfarm that deals with multiple
> branches.
Yeah, you need the code tree of the past instance as well as the
regression tests need to be run on the instance to upgrade.
> One of the significant pluses to TestUpgradeXversion.pm is that it
> tests upgrading quite a bit more than the standard regression
> database. It also tests all the contrib databases and the isolation
> and pl_regression databases. Several bugs have been found that way,
> IIRC, and we should arguably do something along the same lines for our
> builtin testing.
You have a point here. I did not consider those parts.
> I'll post a follow up when I've had a chance to have a good look at
> what Michael has actually done.
I was thinking about that a bit today, and a nice goal would be to come
up with an infrastructure that could be shared between the buildfarm and
the in-core code. Roughly I think that what I developed could be
changed so as we have TestUpgradeXversion.pm, which the buildfarm could
use, and the in-core TAP tests would be a thin wrapper on top of it.
I doubt also a bit how much people actually use test.sh to run
cross-version upgrades.. 5bab1985 is teaching this lesson.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-02 06:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andres Freund <[email protected]>
2018-03-02 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
@ 2018-03-02 14:04 ` Alvaro Herrera <[email protected]>
1 sibling, 0 replies; 118+ messages in thread
From: Alvaro Herrera @ 2018-03-02 14:04 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Andres Freund <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
Andrew Dunstan wrote:
> One of the significant pluses to TestUpgradeXversion.pm is that it
> tests upgrading quite a bit more than the standard regression
> database. It also tests all the contrib databases and the isolation
> and pl_regression databases.
I think we should definitely be including the src/bin/pg_dump/ test
database in this set of tests (if it isn't already), since that one is
supposed to include comprehensive object type coverage.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-02 06:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andres Freund <[email protected]>
@ 2018-03-02 13:02 ` Michael Paquier <[email protected]>
1 sibling, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2018-03-02 13:02 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers; Andrew Dunstan <[email protected]>
On Thu, Mar 01, 2018 at 10:08:06PM -0800, Andres Freund wrote:
> On 2018-01-26 17:00:26 +0900, Michael Paquier wrote:
>> +elsif (defined($ENV{oldsrc}) &&
>> + defined($ENV{oldbindir}) &&
>> + defined($ENV{oldlibdir}))
>> +{
>> + # A run is wanted on an old version as base.
>> + $oldsrc = $ENV{oldsrc};
>> + $oldbindir = $ENV{oldbindir};
>> + $oldlibdir = $ENV{oldlibdir};
>> + # FIXME: this needs better tuning. Using "." or "$oldlibdir/postgresql"
>> + # causes the regression tests to pass but pg_upgrade to fail afterwards.
>
> Planning to fix it?
This is something I am not completely sure yet how to move on with.
Those areas would need adjustment once we ave a better idea what the
buildfarm can make use of.
>> +# Run regression tests on the old instance, using the binaries of this
>> +# instance. At the same time create a tablespace path needed for the
>> +# tests, similarly to what "make check" creates.
>
> What does "using binaries of this instance" mean? And why?
This refers to the installation of the instance to upgrade, including
pg_regress installed in pgxs.
>> +# Before dumping, get rid of objects not existing in later versions. This
>> +# depends on the version of the old server used, and matters only if the
>> +# old and new source paths
>> +my $oldpgversion;
>> +($result, $oldpgversion, $stderr) =
>> + $oldnode->psql('postgres', qq[SHOW server_version_num;]);
>> +my $fix_sql;
>> +if ($newsrc ne $oldsrc)
>> +{
>> + if ($oldpgversion <= 80400)
>> + {
>> + $fix_sql = "DROP FUNCTION public.myfunc(integer); DROP FUNCTION public.oldstyle_length(integer, text);";
>> + }
>> + else
>> + {
>> + $fix_sql = "DROP FUNCTION public.oldstyle_length(integer, text);";
>> + }
>> + $oldnode->psql('postgres', $fix_sql);
>> +}
>
> I know you copied this, but what?
Doesn't it matter to be able to test cross upgrades where the instance
to upgrade is 8.4?
>> +# Take a dump before performing the upgrade as a base comparison. Note
>> +# that we need to use pg_dumpall from PATH here.
>
> Whe do we need to?
Yeah, this should refer to the pg_dumpall command from the new
instance.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
@ 2018-03-03 14:12 ` Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Peter Eisentraut @ 2018-03-03 14:12 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; pgsql-hackers
On 1/26/18 03:00, Michael Paquier wrote:
> As promised on a recent thread, here is a second tentative to switch
> pg_upgrade's test.sh into a TAP infrastructure.
AFAICT, this still has the same problem as the previous take, namely
that adding a TAP test suite to the pg_upgrade subdirectory will end up
with the build farm client running the pg_upgrade tests twice. What we
likely need here is an update to the build farm client in conjunction
with this.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
@ 2018-03-04 04:04 ` Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andrew Dunstan @ 2018-03-04 04:04 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
On Sun, Mar 4, 2018 at 12:42 AM, Peter Eisentraut
<[email protected]> wrote:
> On 1/26/18 03:00, Michael Paquier wrote:
>> As promised on a recent thread, here is a second tentative to switch
>> pg_upgrade's test.sh into a TAP infrastructure.
>
> AFAICT, this still has the same problem as the previous take, namely
> that adding a TAP test suite to the pg_upgrade subdirectory will end up
> with the build farm client running the pg_upgrade tests twice. What we
> likely need here is an update to the build farm client in conjunction
> with this.
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
Something like this should do the trick.
diff --git a/PGBuild/Modules/TestUpgrade.pm b/PGBuild/Modules/TestUpgrade.pm
index 8406d27..05859f9 100644
--- a/PGBuild/Modules/TestUpgrade.pm
+++ b/PGBuild/Modules/TestUpgrade.pm
@@ -50,6 +50,11 @@ sub setup
"overly long build root $buildroot will cause upgrade problems - try
something shorter than 46 chars"
if (length($buildroot) > 46);
+ # don't run module if builtin test is enabled.
+ my $using_tap_tests = $conf->using_msvc ? $conf->{config}->{tap_tests} :
+ grep {$_ eq '--enable-tap-tests'} @{$conf->{config}} ;
+ return if $using_tap_tests && -d
"$buildroot/$branch/pgsql/src/bin/pg_upgrade/t";
+
# could even set up several of these (e.g. for different branches)
my $self = {
buildroot => $buildroot,
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
@ 2018-03-04 21:09 ` Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andrew Dunstan @ 2018-03-04 21:09 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
On Sun, Mar 4, 2018 at 2:34 PM, Andrew Dunstan
<[email protected]> wrote:
> On Sun, Mar 4, 2018 at 12:42 AM, Peter Eisentraut
> <[email protected]> wrote:
>> On 1/26/18 03:00, Michael Paquier wrote:
>>> As promised on a recent thread, here is a second tentative to switch
>>> pg_upgrade's test.sh into a TAP infrastructure.
>>
>> AFAICT, this still has the same problem as the previous take, namely
>> that adding a TAP test suite to the pg_upgrade subdirectory will end up
>> with the build farm client running the pg_upgrade tests twice. What we
>> likely need here is an update to the build farm client in conjunction
>> with this.
>>
>> --
>> Peter Eisentraut http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>
>
> Something like this should do the trick.
[ tiny patch]
Pushed with a bug fix. See
<https://github.com/PGBuildFarm/client-code/commit/826d450eff05d15c8bb3c5b2728da5328634a588;
If you want to do this soon I can put out a Buildfarm Client release
fairly quickly.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
@ 2018-03-06 20:13 ` Peter Eisentraut <[email protected]>
2018-03-06 21:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Tom Lane <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Peter Eisentraut @ 2018-03-06 20:13 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; pgsql-hackers
On 3/4/18 16:09, Andrew Dunstan wrote:
>>> AFAICT, this still has the same problem as the previous take, namely
>>> that adding a TAP test suite to the pg_upgrade subdirectory will end up
>>> with the build farm client running the pg_upgrade tests twice. What we
>>> likely need here is an update to the build farm client in conjunction
>>> with this.
> Pushed with a bug fix. See
> <https://github.com/PGBuildFarm/client-code/commit/826d450eff05d15c8bb3c5b2728da5328634a588;
>
> If you want to do this soon I can put out a Buildfarm Client release
> fairly quickly.
I think the dependency is mostly the other way around. How quickly
would build farm owners install the upgrade?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
@ 2018-03-06 21:12 ` Tom Lane <[email protected]>
2018-03-21 14:51 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two David Steele <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Tom Lane @ 2018-03-06 21:12 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
Peter Eisentraut <[email protected]> writes:
> On 3/4/18 16:09, Andrew Dunstan wrote:
>> If you want to do this soon I can put out a Buildfarm Client release
>> fairly quickly.
> I think the dependency is mostly the other way around. How quickly
> would build farm owners install the upgrade?
IIUC, the buildfarm script patch is only needed to avoid duplicate
tests. So owners need only install it if they want to reduce wasted
cycles on their machines. That being the case, it's only urgent to
the extent that the individual owner perceives it to be. Some might
think it is so, so I'd like to see the BF release available before
we push the TAP test ... but we don't have to wait very long between.
regards, tom lane
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-06 21:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Tom Lane <[email protected]>
@ 2018-03-21 14:51 ` David Steele <[email protected]>
2018-03-22 01:39 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: David Steele @ 2018-03-21 14:51 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On 3/6/18 4:12 PM, Tom Lane wrote:
> Peter Eisentraut <[email protected]> writes:
>> On 3/4/18 16:09, Andrew Dunstan wrote:
>>> If you want to do this soon I can put out a Buildfarm Client release
>>> fairly quickly.
>
>> I think the dependency is mostly the other way around. How quickly
>> would build farm owners install the upgrade?
>
> IIUC, the buildfarm script patch is only needed to avoid duplicate
> tests. So owners need only install it if they want to reduce wasted
> cycles on their machines. That being the case, it's only urgent to
> the extent that the individual owner perceives it to be. Some might
> think it is so, so I'd like to see the BF release available before
> we push the TAP test ... but we don't have to wait very long between.
It seems the consensus is that we'll need a build farm update before we
can move forward with the patch and that we don't need to wait long for
people to upgrade.
Andrew, do you have a date for the next release?
Thanks,
--
-David
[email protected]
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-06 21:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Tom Lane <[email protected]>
2018-03-21 14:51 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two David Steele <[email protected]>
@ 2018-03-22 01:39 ` Michael Paquier <[email protected]>
2018-03-22 01:42 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Craig Ringer <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2018-03-22 01:39 UTC (permalink / raw)
To: David Steele <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Wed, Mar 21, 2018 at 10:51:04AM -0400, David Steele wrote:
> On 3/6/18 4:12 PM, Tom Lane wrote:
> It seems the consensus is that we'll need a build farm update before we
> can move forward with the patch and that we don't need to wait long for
> people to upgrade.
>
> Andrew, do you have a date for the next release?
Even if a lighter version of this patch stripped from multi-version
support (Who uses that actually?) knowing that the buildfarm code has
its own set of modules to do the same may be a good step forward as per
the feedback of this thread people would like to unify the existing
scripts.
We could also try to figure later on how to merge the buildfarm code
into upstream and if it actually makes sense or not, which is something
I am not completely convinced is worth it. This would remove the need
of any complicated refactoring in PostgresNode.pm to handle binary paths
for a single node, at the cost of of course removing cross-upgrade
checks from the tree.
Still I definitely agree that a release of the buildfarm client should
happen first. 9 days before the end of the commit, the window may be at
the end too short for v11.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-06 21:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Tom Lane <[email protected]>
2018-03-21 14:51 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two David Steele <[email protected]>
2018-03-22 01:39 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
@ 2018-03-22 01:42 ` Craig Ringer <[email protected]>
2018-03-22 01:49 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Craig Ringer @ 2018-03-22 01:42 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: David Steele <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On 22 March 2018 at 09:39, Michael Paquier <[email protected]> wrote:
> On Wed, Mar 21, 2018 at 10:51:04AM -0400, David Steele wrote:
> > On 3/6/18 4:12 PM, Tom Lane wrote:
> > It seems the consensus is that we'll need a build farm update before we
> > can move forward with the patch and that we don't need to wait long for
> > people to upgrade.
> >
> > Andrew, do you have a date for the next release?
>
> Even if a lighter version of this patch stripped from multi-version
> support (Who uses that actually?)
I'm super excited by the idea of multi-version support in TAP, if that's
what you mean.
Why? Because I use TAP heavily in extensions. Especially replication
extensions. Which like to talk across multiple versions. I currently need
external test frameworks and some hideous hacks to do this.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-06 21:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Tom Lane <[email protected]>
2018-03-21 14:51 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two David Steele <[email protected]>
2018-03-22 01:39 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-22 01:42 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Craig Ringer <[email protected]>
@ 2018-03-22 01:49 ` Michael Paquier <[email protected]>
2018-04-02 14:35 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2018-03-22 01:49 UTC (permalink / raw)
To: Craig Ringer <[email protected]>; +Cc: David Steele <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Thu, Mar 22, 2018 at 09:42:35AM +0800, Craig Ringer wrote:
> I'm super excited by the idea of multi-version support in TAP, if that's
> what you mean.
>
> Why? Because I use TAP heavily in extensions. Especially replication
> extensions. Which like to talk across multiple versions. I currently need
> external test frameworks and some hideous hacks to do this.
Okay, in front of such enthusiasm we could keep at least the refactoring
part of PostgresNode.pm :)
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-06 21:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Tom Lane <[email protected]>
2018-03-21 14:51 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two David Steele <[email protected]>
2018-03-22 01:39 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-22 01:42 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Craig Ringer <[email protected]>
2018-03-22 01:49 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
@ 2018-04-02 14:35 ` Peter Eisentraut <[email protected]>
2018-04-03 06:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Peter Eisentraut @ 2018-04-02 14:35 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Craig Ringer <[email protected]>; +Cc: David Steele <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On 3/21/18 21:49, Michael Paquier wrote:
> On Thu, Mar 22, 2018 at 09:42:35AM +0800, Craig Ringer wrote:
>> I'm super excited by the idea of multi-version support in TAP, if that's
>> what you mean.
>>
>> Why? Because I use TAP heavily in extensions. Especially replication
>> extensions. Which like to talk across multiple versions. I currently need
>> external test frameworks and some hideous hacks to do this.
>
> Okay, in front of such enthusiasm we could keep at least the refactoring
> part of PostgresNode.pm :)
I took a quick look at that part. It appears to be quite invasive, more
than I would have hoped. Basically, it imposes that from now on all
program invocations must observe the bindir setting, which someone is
surely going to forget. The pg_upgrade tests aren't going to exercise
all possible paths where programs are called, so this is going to lead
to omissions and inconsistencies -- which will then possibly only be
found much later by the extensions that Craig was talking about. I'd
like to see this more isolated, maybe via a path change, or something
inside system_or_bail or something less invasive and more maintainable.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-06 21:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Tom Lane <[email protected]>
2018-03-21 14:51 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two David Steele <[email protected]>
2018-03-22 01:39 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-22 01:42 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Craig Ringer <[email protected]>
2018-03-22 01:49 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-04-02 14:35 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
@ 2018-04-03 06:04 ` Michael Paquier <[email protected]>
2018-04-09 00:38 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2018-04-03 06:04 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Craig Ringer <[email protected]>; David Steele <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Mon, Apr 02, 2018 at 10:35:09AM -0400, Peter Eisentraut wrote:
> I took a quick look at that part. It appears to be quite invasive, more
> than I would have hoped. Basically, it imposes that from now on all
> program invocations must observe the bindir setting, which someone is
> surely going to forget. The pg_upgrade tests aren't going to exercise
> all possible paths where programs are called, so this is going to lead
> to omissions and inconsistencies -- which will then possibly only be
> found much later by the extensions that Craig was talking about. I'd
> like to see this more isolated, maybe via a path change, or something
> inside system_or_bail or something less invasive and more maintainable.
Hm. PostgresNode.pm uses now a couple of different ways to trigger
commands, which makes the problem harder than it seems:
- system_or_bail
- system_log
- IPC::Run::timeout
- IPC::Run::run
Because of that, and if one wants to minimize the number of places where
bindir is called, would be to modify the command strings themselves.
What I could think of would be to have a wrapper like build_bin_path
which adds $bindir on top of the binary, but that would still cause all
the callers to use this wrapper. The use of this wrapper could still be
forgotten.
Enforcing PATH temporarily in a code path or another implies that the
previous value of PATH needs to be added back, which could be forgotten
as well.
At the end, it seems to me that what I am proposing is themost readable
approach, and with proper documentation things should be handled
finely... Or there is an approach you have in mind I do not foresee?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take two
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-06 21:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Tom Lane <[email protected]>
2018-03-21 14:51 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two David Steele <[email protected]>
2018-03-22 01:39 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-22 01:42 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Craig Ringer <[email protected]>
2018-03-22 01:49 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-04-02 14:35 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-04-03 06:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
@ 2018-04-09 00:38 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2018-04-09 00:38 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Craig Ringer <[email protected]>; David Steele <[email protected]>; Andrew Dunstan <[email protected]>; Tom Lane <[email protected]>; Michael Paquier <[email protected]>; pgsql-hackers
On Tue, Apr 03, 2018 at 03:04:10PM +0900, Michael Paquier wrote:
> At the end, it seems to me that what I am proposing is themost readable
> approach, and with proper documentation things should be handled
> finely... Or there is an approach you have in mind I do not foresee?
With feature freeze which has been reached, I am marking this patch as
returned with feedback. Please note that I have no plans to resubmit
again this patch set after this second attempt as I have no idea where
we want things to go.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* jsonb iterator not fully initialized
@ 2018-05-26 00:02 Peter Eisentraut <[email protected]>
2018-05-26 07:09 ` Re: jsonb iterator not fully initialized Piotr Stefaniak <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Peter Eisentraut @ 2018-05-26 00:02 UTC (permalink / raw)
To: pgsql-hackers
I got this error message via -fsanitized=undefined:
jsonfuncs.c:5169:12: runtime error: load of value 127, which is not a
valid value for type '_Bool'
The query was
select ts_headline('{}'::jsonb, tsquery('aaa & bbb'));
This calls the C function ts_headline_jsonb_byid_opt(), which calls
transform_jsonb_string_values(), which calls
it = JsonbIteratorInit(&jsonb->root);
is_scalar = it->isScalar;
but it->isScalar is not always initialized by JsonbIteratorInit(). (So
the 127 is quite likely clobbered memory.)
It can be fixed this way:
--- a/src/backend/utils/adt/jsonb_util.c
+++ b/src/backend/utils/adt/jsonb_util.c
@@ -901,7 +901,7 @@ iteratorFromContainer(JsonbContainer *container,
JsonbIterator *parent)
{
JsonbIterator *it;
- it = palloc(sizeof(JsonbIterator));
+ it = palloc0(sizeof(JsonbIterator));
it->container = container;
it->parent = parent;
it->nElems = JsonContainerSize(container);
It's probably not a problem in practice, since the isScalar business is
apparently only used in the array case, but it's dubious to leave things
uninitialized like this nonetheless.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: jsonb iterator not fully initialized
2018-05-26 00:02 jsonb iterator not fully initialized Peter Eisentraut <[email protected]>
@ 2018-05-26 07:09 ` Piotr Stefaniak <[email protected]>
2018-05-26 14:47 ` Re: jsonb iterator not fully initialized Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Piotr Stefaniak @ 2018-05-26 07:09 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; pgsql-hackers
On 2018-05-26 02:02, Peter Eisentraut wrote:
> I got this error message via -fsanitized=undefined:
>
> jsonfuncs.c:5169:12: runtime error: load of value 127, which is not a
> valid value for type '_Bool'
>
> The query was
>
> select ts_headline('{}'::jsonb, tsquery('aaa & bbb'));
>
> This calls the C function ts_headline_jsonb_byid_opt(), which calls
> transform_jsonb_string_values(), which calls
>
> it = JsonbIteratorInit(&jsonb->root);
> is_scalar = it->isScalar;
>
> but it->isScalar is not always initialized by JsonbIteratorInit(). (So
> the 127 is quite likely clobbered memory.)
>
> It can be fixed this way:
>
> --- a/src/backend/utils/adt/jsonb_util.c
> +++ b/src/backend/utils/adt/jsonb_util.c
> @@ -901,7 +901,7 @@ iteratorFromContainer(JsonbContainer *container,
> JsonbIterator *parent)
> {
> JsonbIterator *it;
>
> - it = palloc(sizeof(JsonbIterator));
> + it = palloc0(sizeof(JsonbIterator));
> it->container = container;
> it->parent = parent;
> it->nElems = JsonContainerSize(container);
>
> It's probably not a problem in practice, since the isScalar business is
> apparently only used in the array case, but it's dubious to leave things
> uninitialized like this nonetheless.
>
I've seen it earlier but couldn't decide what my proposed fix should
look like. One of the options I considered was:
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/adt/jsonfuncs.c
@@ -5010,10 +5010,8 @@ transform_jsonb_string_values(Jsonb *jsonb, void
*action_state,
JsonbIteratorToken type;
JsonbParseState *st = NULL;
text *out;
- bool is_scalar = false;
it = JsonbIteratorInit(&jsonb->root);
- is_scalar = it->isScalar;
while ((type = JsonbIteratorNext(&it, &v, false)) != WJB_DONE)
{
@@ -5033,7 +5031,7 @@ transform_jsonb_string_values(Jsonb *jsonb, void
*action_state,
}
if (res->type == jbvArray)
- res->val.array.rawScalar = is_scalar;
+ res->val.array.rawScalar =
JsonContainerIsScalar(&jsonb->root);
return JsonbValueToJsonb(res);
}
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: jsonb iterator not fully initialized
2018-05-26 00:02 jsonb iterator not fully initialized Peter Eisentraut <[email protected]>
2018-05-26 07:09 ` Re: jsonb iterator not fully initialized Piotr Stefaniak <[email protected]>
@ 2018-05-26 14:47 ` Andrew Dunstan <[email protected]>
2018-05-27 20:40 ` Re: jsonb iterator not fully initialized Dmitry Dolgov <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andrew Dunstan @ 2018-05-26 14:47 UTC (permalink / raw)
To: Piotr Stefaniak <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
On 05/26/2018 03:09 AM, Piotr Stefaniak wrote:
> On 2018-05-26 02:02, Peter Eisentraut wrote:
>> I got this error message via -fsanitized=undefined:
>>
>> jsonfuncs.c:5169:12: runtime error: load of value 127, which is not a
>> valid value for type '_Bool'
>>
>> The query was
>>
>> select ts_headline('{}'::jsonb, tsquery('aaa & bbb'));
>>
>> This calls the C function ts_headline_jsonb_byid_opt(), which calls
>> transform_jsonb_string_values(), which calls
>>
>> it = JsonbIteratorInit(&jsonb->root);
>> is_scalar = it->isScalar;
>>
>> but it->isScalar is not always initialized by JsonbIteratorInit(). (So
>> the 127 is quite likely clobbered memory.)
>>
>> It can be fixed this way:
>>
>> --- a/src/backend/utils/adt/jsonb_util.c
>> +++ b/src/backend/utils/adt/jsonb_util.c
>> @@ -901,7 +901,7 @@ iteratorFromContainer(JsonbContainer *container,
>> JsonbIterator *parent)
>> {
>> JsonbIterator *it;
>>
>> - it = palloc(sizeof(JsonbIterator));
>> + it = palloc0(sizeof(JsonbIterator));
>> it->container = container;
>> it->parent = parent;
>> it->nElems = JsonContainerSize(container);
>>
>> It's probably not a problem in practice, since the isScalar business is
>> apparently only used in the array case, but it's dubious to leave things
>> uninitialized like this nonetheless.
>>
> I've seen it earlier but couldn't decide what my proposed fix should
> look like. One of the options I considered was:
>
> --- a/src/backend/utils/adt/jsonfuncs.c
> +++ b/src/backend/utils/adt/jsonfuncs.c
> @@ -5010,10 +5010,8 @@ transform_jsonb_string_values(Jsonb *jsonb, void
> *action_state,
> JsonbIteratorToken type;
> JsonbParseState *st = NULL;
> text *out;
> - bool is_scalar = false;
>
> it = JsonbIteratorInit(&jsonb->root);
> - is_scalar = it->isScalar;
>
> while ((type = JsonbIteratorNext(&it, &v, false)) != WJB_DONE)
> {
> @@ -5033,7 +5031,7 @@ transform_jsonb_string_values(Jsonb *jsonb, void
> *action_state,
> }
>
> if (res->type == jbvArray)
> - res->val.array.rawScalar = is_scalar;
> + res->val.array.rawScalar =
> JsonContainerIsScalar(&jsonb->root);
>
> return JsonbValueToJsonb(res);
> }
palloc0 seems cleaner.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: jsonb iterator not fully initialized
2018-05-26 00:02 jsonb iterator not fully initialized Peter Eisentraut <[email protected]>
2018-05-26 07:09 ` Re: jsonb iterator not fully initialized Piotr Stefaniak <[email protected]>
2018-05-26 14:47 ` Re: jsonb iterator not fully initialized Andrew Dunstan <[email protected]>
@ 2018-05-27 20:40 ` Dmitry Dolgov <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Dmitry Dolgov @ 2018-05-27 20:40 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Piotr Stefaniak <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
> On 26 May 2018 at 16:47, Andrew Dunstan <[email protected]> wrote:
> On 05/26/2018 03:09 AM, Piotr Stefaniak wrote:
>> On 2018-05-26 02:02, Peter Eisentraut wrote:
>>>
>>> It can be fixed this way:
>>>
>>> --- a/src/backend/utils/adt/jsonb_util.c
>>> +++ b/src/backend/utils/adt/jsonb_util.c
>>> @@ -901,7 +901,7 @@ iteratorFromContainer(JsonbContainer *container,
>>> JsonbIterator *parent)
>>> {
>>> JsonbIterator *it;
>>>
>>> - it = palloc(sizeof(JsonbIterator));
>>> + it = palloc0(sizeof(JsonbIterator));
>>> it->container = container;
>>> it->parent = parent;
>>> it->nElems = JsonContainerSize(container);
>>>
>>> It's probably not a problem in practice, since the isScalar business is
>>> apparently only used in the array case, but it's dubious to leave things
>>> uninitialized like this nonetheless.
Yes, sounds reasonable.
>> I've seen it earlier but couldn't decide what my proposed fix should
>> look like. One of the options I considered was:
>>
>> --- a/src/backend/utils/adt/jsonfuncs.c
>> +++ b/src/backend/utils/adt/jsonfuncs.c
>> @@ -5010,10 +5010,8 @@ transform_jsonb_string_values(Jsonb *jsonb, void
>> *action_state,
>> JsonbIteratorToken type;
>> JsonbParseState *st = NULL;
>> text *out;
>> - bool is_scalar = false;
>>
>> it = JsonbIteratorInit(&jsonb->root);
>> - is_scalar = it->isScalar;
>>
>> while ((type = JsonbIteratorNext(&it, &v, false)) != WJB_DONE)
>> {
>> @@ -5033,7 +5031,7 @@ transform_jsonb_string_values(Jsonb *jsonb, void
>> *action_state,
>> }
>>
>> if (res->type == jbvArray)
>> - res->val.array.rawScalar = is_scalar;
>> + res->val.array.rawScalar =
>> JsonContainerIsScalar(&jsonb->root);
>>
>> return JsonbValueToJsonb(res);
>> }
>
> palloc0 seems cleaner.
Totally agree, palloc0 looks better (although I assume it's going to be
negligibly slower in those cases that aren't affected by this problem).
^ permalink raw reply [nested|flat] 118+ messages in thread
* Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
@ 2021-05-15 02:26 Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2021-05-15 02:26 UTC (permalink / raw)
To: Postgres hackers <[email protected]>
Hi,
(Adding Andrew in CC for the buildfarm and PostgresNode parts.)
$subject has been around for a couple of years now, with the following
threads:
https://www.postgresql.org/message-id/[email protected]
https://www.postgresql.org/message-id/[email protected]...
An advantage of moving to TAP is that we can then remove the support
for upgrades within the MSVC scripts, and also remove pg_upgrade's
test.sh that has accumulated tweaks that are solved by the TAP tests,
resulting in cleanup:
8 files changed, 230 insertions(+), 403 deletions(-)
Based on the past discussions, there were two obstacles preventing to
do this switch:
- Support for tests with older versions, something where the gap as
been closed thanks to Andrew's work in 4c4eaf3d.
- Buildfarm support, and I am not sure how things need to be extended
there.
Another thing to note is that HEAD uses oldbindir, bindir and libdir
to track the location of the old and new libraries and binaries. With
the infrastructure in place, once can define only an install path for
a PostgresNode, so this version uses only two variables:
- oldinstall, for the installation path of the version to upgrade
from.
- oldsrc, to point to the source of the old version.
It is not difficult to switch to one approach or the other, but
reducing the logic to a minimum number of variables is a good deal to
take IMO.
I have been testing this patch a bit with older versions, down to 12,
and that was logically working, and PostgresNode may need more to be
able to work with ~11, as documented in get_new_node(). And I have
not tested that with MSVC yet. Anyway, attached is a new patch to
make the discussion move on. Even if there is still work to be done
here, would people here still support this switch?
Thanks,
--
Michael
Attachments:
[text/x-diff] 0001-Switch-tests-of-pg_upgrade-to-use-TAP.patch (24.2K, ../../[email protected]/2-0001-Switch-tests-of-pg_upgrade-to-use-TAP.patch)
download | inline diff:
From 557e1bd4cea5e1081ea77e364c3e7f37ad3c5268 Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email protected]>
Date: Sat, 15 May 2021 10:44:18 +0900
Subject: [PATCH] Switch tests of pg_upgrade to use TAP
---
src/bin/pg_upgrade/Makefile | 17 +-
src/bin/pg_upgrade/TESTING | 9 +-
src/bin/pg_upgrade/t/001_basic.pl | 9 +
src/bin/pg_upgrade/t/002_pg_upgrade.pl | 188 +++++++++++++++++
src/bin/pg_upgrade/test.sh | 272 -------------------------
src/test/perl/PostgresNode.pm | 25 +++
doc/src/sgml/install-windows.sgml | 1 -
src/tools/msvc/vcregress.pl | 112 +---------
8 files changed, 230 insertions(+), 403 deletions(-)
create mode 100644 src/bin/pg_upgrade/t/001_basic.pl
create mode 100644 src/bin/pg_upgrade/t/002_pg_upgrade.pl
delete mode 100644 src/bin/pg_upgrade/test.sh
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 44d06be5a6..fa8dee0a9c 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -49,17 +49,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-# When $(MAKE) is present, make automatically infers that this is a
-# recursive make. which is not actually what we want here, as that
-# e.g. prevents output synchronization from working (as make thinks
-# that the subsidiary make knows how to deal with that itself, but
-# we're invoking a shell script that doesn't know). Referencing
-# $(MAKE) indirectly avoids that behaviour.
-# See https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable
-NOTSUBMAKEMAKE=$(MAKE)
+check:
+ $(prove_check)
-check: test.sh all temp-install
- MAKE=$(NOTSUBMAKEMAKE) $(with_temp_install) bindir=$(abs_top_builddir)/tmp_install/$(bindir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $<
-
-# installcheck is not supported because there's no meaningful way to test
-# pg_upgrade against a single already-running server
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
index e69874b42d..b589bcaf6d 100644
--- a/src/bin/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -9,14 +9,11 @@ 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:
+source tree for the old version as well as this version. 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
+export oldinstall=...otherversion/bin (old version's install base path)
+make check
In this case, you will have to manually eyeball the resulting dump
diff for version-specific differences, as explained below.
diff --git a/src/bin/pg_upgrade/t/001_basic.pl b/src/bin/pg_upgrade/t/001_basic.pl
new file mode 100644
index 0000000000..605a7f622f
--- /dev/null
+++ b/src/bin/pg_upgrade/t/001_basic.pl
@@ -0,0 +1,9 @@
+use strict;
+use warnings;
+
+use TestLib;
+use Test::More tests => 8;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
new file mode 100644
index 0000000000..263aa9525b
--- /dev/null
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -0,0 +1,188 @@
+# Set of tests for pg_upgrade.
+use strict;
+use warnings;
+
+use Cwd qw(abs_path getcwd);
+use File::Basename qw(dirname);
+
+use PostgresNode;
+use TestLib;
+use Test::More tests => 4;
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log([ 'createdb', '--port', $node->port, $dbname ]);
+}
+
+my $startdir = getcwd();
+
+# From now on, the test of pg_upgrade consists in setting up an instance
+# on which regression tests are run. This is the source instance used
+# for the upgrade. Then a new, fresh, instance is created, and is used
+# as the target instance for the upgrade. Before running an upgrade a
+# logical dump of the old instance is taken, and a second logical dump
+# of the new instance is taken after the upgrade. The upgrade test
+# passes if there are no differences after running pg_upgrade.
+
+# Testing upgrades with an older instance of PostgreSQL requires
+# setting up two environment variables:
+# - "oldsrc", to point to the code source of the older version.
+# - "oldinstall", to point to the installation path of the older
+# version.
+
+# Default is the location of this source code for both nodes used with
+# the upgrade.
+my $newsrc = abs_path("../../..");
+my $oldsrc = $ENV{oldsrc} || $newsrc;
+$oldsrc = abs_path($oldsrc);
+
+if ( (defined($ENV{oldsrc}) && !defined($ENV{oldinstall}))
+ || (!defined($ENV{oldsrc}) && defined($ENV{oldinstall})))
+{
+ # Not all variables are defined, so leave and die if test is
+ # done with an older installation.
+ die "oldsrc or oldinstall is undefined";
+}
+
+if (defined($ENV{oldsrc}) && $windows_os)
+{
+ # This configuration is not supported on Windows, as regress.so
+ # location diverges across the compilation methods used on this
+ # platform.
+ # XXX: this could likely be lifted.
+ die "No support for older version tests on Windows";
+}
+
+# Temporary location for the dumps taken
+my $tempdir = TestLib::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = get_new_node('old_node', install_path => $ENV{oldinstall});
+
+$oldnode->init(extra => [ '--locale', 'C', '--encoding', 'LATIN1' ]);
+$oldnode->start;
+
+# Creating databases with names covering most ASCII bytes
+generate_db($oldnode, 1, 45);
+generate_db($oldnode, 46, 90);
+generate_db($oldnode, 91, 127);
+
+# Run core regression tests on the old instance.
+$oldnode->run_log([ "createdb", '--port', $oldnode->port, 'regression' ]);
+
+# This is more a trick than anything else, as pg_regress needs to be
+# from the old instance. --dlpath is needed to be able to find the
+# location of regress.so, and is located normally in the same folder
+# as pg_regress itself.
+my $bindir = $oldnode->bin_dir;
+chdir "$oldsrc/src/test/regress/";
+$oldnode->command_ok(
+ [
+ $ENV{PG_REGRESS}, '--schedule',
+ 'parallel_schedule', '--bindir',
+ $oldnode->bin_dir, '--dlpath',
+ '.', '--use-existing',
+ '--port', $oldnode->port
+ ],
+ 'regression test run on old instance');
+
+# Before dumping, get rid of objects not existing in later versions. This
+# depends on the version of the old server used, and matters only if the
+# old and new source paths
+my ($result, $oldpgversion, $stderr) =
+ $oldnode->psql('postgres', qq[SHOW server_version_num;]);
+my $fix_sql;
+if ($newsrc ne $oldsrc)
+{
+ if ($oldpgversion <= 80400)
+ {
+ $fix_sql =
+ "DROP FUNCTION public.myfunc(integer); DROP FUNCTION public.oldstyle_length(integer, text);";
+ }
+ else
+ {
+ $fix_sql = "DROP FUNCTION public.oldstyle_length(integer, text);";
+ }
+ $oldnode->psql('postgres', $fix_sql);
+}
+
+# Initialize a new node for the upgrade. This is done early so as it is
+# possible to know with which node's PATH the initial dump needs to be
+# taken.
+my $newnode = get_new_node('new_node');
+$newnode->init(extra => [ '--locale=C', '--encoding=LATIN1' ]);
+
+# Take a dump before performing the upgrade as a base comparison. Note
+# that we need to use pg_dumpall from the new node here.
+$newnode->command_ok(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $oldnode->connstr('postgres'),
+ '-f', "$tempdir/dump1.sql"
+ ],
+ 'dump before running pg_upgrade');
+
+# After dumping, update references to the old source tree's regress.so and
+# such.
+if ($newsrc ne $oldsrc)
+{
+ if ($oldpgversion <= 80400)
+ {
+ $fix_sql =
+ "UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%';";
+ }
+ else
+ {
+ $fix_sql =
+ "UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';";
+ }
+ $oldnode->psql('postgres', $fix_sql);
+
+ my $dump_data = slurp_file("$tempdir/dump1.sql");
+ $dump_data =~ s/$oldsrc/$newsrc/g;
+
+ open my $fh, ">", "$tempdir/dump1.sql" or die "could not open dump file";
+ print $fh $dump_data;
+ close $fh;
+}
+
+# Move back to current directory, all logs generated need to be located
+# at the origin.
+chdir $startdir;
+
+# Update the instance.
+$oldnode->stop;
+
+# Time for the real run.
+chdir "$newsrc/src/test/regress";
+my $newbindir = $newnode->bin_dir;
+$newnode->command_ok(
+ [
+ 'pg_upgrade', '-d', $oldnode->data_dir, '-D',
+ $newnode->data_dir, '-b', $oldnode->bin_dir, '-B',
+ $newnode->bin_dir, '-p', $oldnode->port, '-P',
+ $newnode->port
+ ],
+ 'run of pg_upgrade for new instance');
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+$newnode->run_log(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $newnode->connstr('postgres'),
+ '-f', "$tempdir/dump2.sql"
+ ]);
+
+# Compare the two dumps, there should be no differences.
+command_ok([ 'diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql" ],
+ 'Old and new dump match after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index 1ba326decd..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,272 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2021, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- # To increase coverage of non-standard segment size and group access
- # without increasing test runtime, run these tests with a custom setting.
- # Also, specify "-A trust" explicitly to suppress initdb's warning.
- "$1" -N --wal-segsize 1 -g -A trust
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# What flavor of host are we on?
-# Treat MINGW* (msys1) and MSYS* (msys2) the same.
-testhost=`uname -s | sed 's/^MSYS/MINGW/'`
-
-# Establish how the server will listen for connections
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PG_REGRESS_SOCKET_DIR=""
- PGHOST=localhost
- ;;
- *)
- LISTEN_ADDRESSES=""
- # Select a socket directory. The algorithm is from the "configure"
- # script; the outcome mimics pg_regress.c:make_temp_sockdir().
- if [ x"$PG_REGRESS_SOCKET_DIR" = x ]; then
- set +e
- dir=`(umask 077 &&
- mktemp -d /tmp/pg_upgrade_check-XXXXXX) 2>/dev/null`
- if [ ! -d "$dir" ]; then
- dir=/tmp/pg_upgrade_check-$$-$RANDOM
- (umask 077 && mkdir "$dir")
- if [ ! -d "$dir" ]; then
- echo "could not create socket temporary directory in \"/tmp\""
- exit 1
- fi
- fi
- set -e
- PG_REGRESS_SOCKET_DIR=$dir
- trap 'rm -rf "$PG_REGRESS_SOCKET_DIR"' 0
- trap 'exit 3' 1 2 13 15
- fi
- PGHOST=$PG_REGRESS_SOCKET_DIR
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=\"$LISTEN_ADDRESSES\" -k \"$PG_REGRESS_SOCKET_DIR\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-temp_root=`pwd`/tmp_check
-rm -rf "$temp_root"
-mkdir "$temp_root"
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-# We need to make pg_regress use psql from the desired installation
-# (likely a temporary one), because otherwise the installcheck run
-# below would try to use psql from the proper installation directory
-# of the target version, which might be outdated or not exist. But
-# don't override anything else that's already in EXTRA_REGRESS_OPTS.
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$oldbindir'"
-export EXTRA_REGRESS_OPTS
-
-# While in normal cases this will already be set up, adding bindir to
-# path allows test.sh to be invoked with different versions as
-# described in ./TESTING
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA="$temp_root/data"
-PGDATA="${BASE_PGDATA}.old"
-export PGDATA
-
-# Send installcheck outputs to a private directory. This avoids conflict when
-# check-world runs pg_upgrade check concurrently with src/test/regress check.
-# To retrieve interesting files after a run, use pattern tmp_check/*/*.diffs.
-outputdir="$temp_root/regress"
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --outputdir=$outputdir"
-export EXTRA_REGRESS_OPTS
-mkdir "$outputdir"
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "regression$dbname1" || createdb_status=$?
-createdb "regression$dbname2" || createdb_status=$?
-createdb "regression$dbname3" || createdb_status=$?
-
-if "$MAKE" -C "$oldsrc" installcheck-parallel; then
- oldpgversion=`psql -X -A -t -d regression -c "SHOW server_version_num"`
-
- # before dumping, get rid of objects not feasible in later versions
- if [ "$newsrc" != "$oldsrc" ]; then
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="DROP FUNCTION public.myfunc(integer);"
- ;;
- esac
- fix_sql="$fix_sql
- DROP FUNCTION IF EXISTS
- public.oldstyle_length(integer, text); -- last in 9.6
- DROP FUNCTION IF EXISTS
- public.putenv(text); -- last in v13
- DROP OPERATOR IF EXISTS -- last in v13
- public.#@# (pg_catalog.int8, NONE),
- public.#%# (pg_catalog.int8, NONE),
- public.!=- (pg_catalog.int8, NONE),
- public.#@%# (pg_catalog.int8, NONE);"
- psql -X -d regression -c "$fix_sql;" || psql_fix_sql_status=$?
- fi
-
- pg_dumpall --no-sync -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
-
- if [ "$newsrc" != "$oldsrc" ]; then
- # update references to old source tree's regress.so etc
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%';"
- ;;
- *)
- fix_sql="UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';"
- ;;
- esac
- psql -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA="$BASE_PGDATA"
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "$PGDATA" -b "$oldbindir" -p "$PGPORT" -P "$PGPORT"
-
-# make sure all directories and files have group permissions, on Unix hosts
-# Windows hosts don't support Unix-y permissions.
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type f ! -perm 640 | wc -l` -ne 0 ]; then
- echo "files in PGDATA with permission != 640";
- exit 1;
- fi ;;
-esac
-
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type d ! -perm 750 | wc -l` -ne 0 ]; then
- echo "directories in PGDATA with permission != 750";
- exit 1;
- fi ;;
-esac
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-pg_dumpall --no-sync -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) MSYS2_ARG_CONV_EXCL=/c cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm
index f7088667a4..45147b9c20 100644
--- a/src/test/perl/PostgresNode.pm
+++ b/src/test/perl/PostgresNode.pm
@@ -340,6 +340,31 @@ sub backup_dir
=pod
+=item $node->bin_dir()
+
+The path to the binaries of the node.
+
+=cut
+
+sub bin_dir
+{
+ my ($self) = @_;
+ local %ENV = $self->_get_env();
+
+ # Find the information from pg_config --bindir
+ my ($stdout, $stderr);
+ my $result =
+ IPC::Run::run [ $self->installed_command('pg_config'), '--bindir' ],
+ '>', \$stdout, '2>', \$stderr
+ or die "could not execute pg_config";
+ chomp($stdout);
+ $stdout =~ s/\r$//;
+
+ return $stdout;
+}
+
+=pod
+
=item $node->info()
Return a string containing human-readable diagnostic information (paths, etc)
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 92087dba68..55e271897c 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -469,7 +469,6 @@ $ENV{CONFIG}="Debug";
<userinput>vcregress isolationcheck</userinput>
<userinput>vcregress bincheck</userinput>
<userinput>vcregress recoverycheck</userinput>
-<userinput>vcregress upgradecheck</userinput>
</screen>
To change the schedule used (default is parallel), append it to the
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index 1852c34109..3a7e663e07 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -41,7 +41,7 @@ if (-e "src/tools/msvc/buildenv.pl")
my $what = shift || "";
if ($what =~
- /^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|upgradecheck|bincheck|recoverycheck|taptest)$/i
+ /^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|bincheck|recoverycheck|taptest)$/i
)
{
$what = uc $what;
@@ -90,7 +90,6 @@ my %command = (
ISOLATIONCHECK => \&isolationcheck,
BINCHECK => \&bincheck,
RECOVERYCHECK => \&recoverycheck,
- UPGRADECHECK => \&upgradecheck,
TAPTEST => \&taptest,);
my $proc = $command{$what};
@@ -549,114 +548,6 @@ sub quote_system_arg
return "\"$arg\"";
}
-# Generate a database with a name made of a range of ASCII characters, useful
-# for testing pg_upgrade.
-sub generate_db
-{
- my ($prefix, $from_char, $to_char, $suffix) = @_;
-
- my $dbname = $prefix;
- for my $i ($from_char .. $to_char)
- {
- next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
- $dbname = $dbname . sprintf('%c', $i);
- }
- $dbname .= $suffix;
-
- system('createdb', quote_system_arg($dbname));
- my $status = $? >> 8;
- exit $status if $status;
- return;
-}
-
-sub upgradecheck
-{
- my $status;
- my $cwd = getcwd();
-
- # Much of this comes from the pg_upgrade test.sh script,
- # but it only covers the --install case, and not the case
- # where the old and new source or bin dirs are different.
- # i.e. only this version to this version check. That's
- # what pg_upgrade's "make check" does.
-
- $ENV{PGHOST} = 'localhost';
- $ENV{PGPORT} ||= 50432;
- my $tmp_root = "$topdir/src/bin/pg_upgrade/tmp_check";
- rmtree($tmp_root);
- mkdir $tmp_root || die $!;
- my $upg_tmp_install = "$tmp_root/install"; # unshared temp install
- print "Setting up temp install\n\n";
- Install($upg_tmp_install, "all", $config);
-
- # Install does a chdir, so change back after that
- chdir $cwd;
- my ($bindir, $libdir, $oldsrc, $newsrc) =
- ("$upg_tmp_install/bin", "$upg_tmp_install/lib", $topdir, $topdir);
- $ENV{PATH} = "$bindir;$ENV{PATH}";
- my $data = "$tmp_root/data";
- $ENV{PGDATA} = "$data.old";
- my $outputdir = "$tmp_root/regress";
- my @EXTRA_REGRESS_OPTS = ("--outputdir=$outputdir");
- mkdir "$outputdir" || die $!;
-
- my $logdir = "$topdir/src/bin/pg_upgrade/log";
- rmtree($logdir);
- mkdir $logdir || die $!;
- print "\nRunning initdb on old cluster\n\n";
- standard_initdb() or exit 1;
- print "\nStarting old cluster\n\n";
- my @args = ('pg_ctl', 'start', '-l', "$logdir/postmaster1.log");
- system(@args) == 0 or exit 1;
-
- print "\nCreating databases with names covering most ASCII bytes\n\n";
- generate_db("\\\"\\", 1, 45, "\\\\\"\\\\\\");
- generate_db('', 46, 90, '');
- generate_db('', 91, 127, '');
-
- print "\nSetting up data for upgrading\n\n";
- installcheck_internal('parallel', @EXTRA_REGRESS_OPTS);
-
- # now we can chdir into the source dir
- chdir "$topdir/src/bin/pg_upgrade";
- print "\nDumping old cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump1.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping old cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- $ENV{PGDATA} = "$data";
- print "\nSetting up new cluster\n\n";
- standard_initdb() or exit 1;
- print "\nRunning pg_upgrade\n\n";
- @args = ('pg_upgrade', '-d', "$data.old", '-D', $data, '-b', $bindir);
- system(@args) == 0 or exit 1;
- print "\nStarting new cluster\n\n";
- @args = ('pg_ctl', '-l', "$logdir/postmaster2.log", 'start');
- system(@args) == 0 or exit 1;
- print "\nDumping new cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump2.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping new cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- print "\nDeleting old cluster\n\n";
- system(".\\delete_old_cluster.bat") == 0 or exit 1;
- print "\nComparing old and new cluster dumps\n\n";
-
- @args = ('diff', '-q', "$tmp_root/dump1.sql", "$tmp_root/dump2.sql");
- system(@args);
- $status = $?;
- if (!$status)
- {
- print "PASSED\n";
- }
- else
- {
- print "dumps not identical!\n";
- exit(1);
- }
- return;
-}
-
sub fetchRegressOpts
{
my $handle;
@@ -777,7 +668,6 @@ sub usage
" plcheck run tests of PL languages\n",
" recoverycheck run recovery test suite\n",
" taptest run an arbitrary TAP test set\n",
- " upgradecheck run tests of pg_upgrade\n",
"\nOptions for <arg>: (used by check and installcheck)\n",
" serial serial mode\n",
" parallel parallel mode\n",
--
2.31.1
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2021-05-15 18:22 ` Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andrew Dunstan @ 2021-05-15 18:22 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Postgres hackers <[email protected]>
On 5/14/21 10:26 PM, Michael Paquier wrote:
> Hi,
> (Adding Andrew in CC for the buildfarm and PostgresNode parts.)
>
> $subject has been around for a couple of years now, with the following
> threads:
> https://www.postgresql.org/message-id/[email protected]
> https://www.postgresql.org/message-id/[email protected]...
>
> An advantage of moving to TAP is that we can then remove the support
> for upgrades within the MSVC scripts, and also remove pg_upgrade's
> test.sh that has accumulated tweaks that are solved by the TAP tests,
> resulting in cleanup:
> 8 files changed, 230 insertions(+), 403 deletions(-)
>
> Based on the past discussions, there were two obstacles preventing to
> do this switch:
> - Support for tests with older versions, something where the gap as
> been closed thanks to Andrew's work in 4c4eaf3d.
> - Buildfarm support, and I am not sure how things need to be extended
> there.
>
> Another thing to note is that HEAD uses oldbindir, bindir and libdir
> to track the location of the old and new libraries and binaries. With
> the infrastructure in place, once can define only an install path for
> a PostgresNode, so this version uses only two variables:
> - oldinstall, for the installation path of the version to upgrade
> from.
> - oldsrc, to point to the source of the old version.
>
> It is not difficult to switch to one approach or the other, but
> reducing the logic to a minimum number of variables is a good deal to
> take IMO.
>
> I have been testing this patch a bit with older versions, down to 12,
> and that was logically working, and PostgresNode may need more to be
> able to work with ~11, as documented in get_new_node(). And I have
> not tested that with MSVC yet. Anyway, attached is a new patch to
> make the discussion move on. Even if there is still work to be done
> here, would people here still support this switch?
PostgresNode is currently able to create nodes suitable for upgrade down
to release 10. If we add '-w' to the 'pg_ctl start' flags that can
extend down to release 9.5. (Just tested) I think we should do that
forthwith. '-w' is now the default, but having it there explicitly does
no harm.
If people are interested in what's incompatible on older versions, they
can look at
<https://gitlab.com/adunstan/postgresnodeng/-/blob/master/PostgresNode.pm;
starting at about line 2764.
I don't think this will work, though, unless there is enough data to
exercise pg_upgrade fairly thoroughly. The approach taken by both
test.sh and (somewhat more comprehensively) by the buildfarm cross
version upgrade module is to test a cluster where the regression tests
have been run. That might be more difficult when testing against older
versions, so I have published a snapshot of the dumps of each of the
versions we tests against in the buildfarm animal crake. These could be
loaded into PostgresNode instances and then an upgrade attempted. See
<https://gitlab.com/adunstan/pg-old-bin/-/tree/master/data;. The data
goes back to 9.2. These compressed dumps are a couple of megabytes each,
not huge.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
@ 2021-05-17 01:55 ` Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2021-05-17 01:55 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Postgres hackers <[email protected]>
On Sat, May 15, 2021 at 02:22:24PM -0400, Andrew Dunstan wrote:
> PostgresNode is currently able to create nodes suitable for upgrade down
> to release 10. If we add '-w' to the 'pg_ctl start' flags that can
> extend down to release 9.5. (Just tested) I think we should do that
> forthwith. '-w' is now the default, but having it there explicitly does
> no harm.
Agreed. When testing manually, I have personally never worked on any
patches that required binaries older than 9.4, so I would be fine if
the TAP tests are able to work easily down to 9.5, even if pg_upgrade
is supported down to 8.4.
> If people are interested in what's incompatible on older versions, they
> can look at
> <https://gitlab.com/adunstan/postgresnodeng/-/blob/master/PostgresNode.pm;
> starting at about line 2764.
We should really have adjust_conf() at some point in the in-core
module.
> I don't think this will work, though, unless there is enough data to
> exercise pg_upgrade fairly thoroughly. The approach taken by both
> test.sh and (somewhat more comprehensively) by the buildfarm cross
> version upgrade module is to test a cluster where the regression tests
> have been run.
Yeah, that's what my patch is doing with pg_regress, FWIW. This
requires regress.so from the old version.
> That might be more difficult when testing against older
> versions, so I have published a snapshot of the dumps of each of the
> versions we tests against in the buildfarm animal crake. These could be
> loaded into PostgresNode instances and then an upgrade attempted. See
> <https://gitlab.com/adunstan/pg-old-bin/-/tree/master/data;. The data
> goes back to 9.2. These compressed dumps are a couple of megabytes each,
> not huge.
I agree that this can be simpler in some cases. In your experience,
how much of an issue is it when it becomes necessary to keep around
binaries that rely on libraries older than what a system can support?
It is easy to counter issues in this area with OpenSSL and
non-necessary things, but we had in the past also cases where we had
code that conflicted with the kernel, aka 3e68686.
At the end of this exercise, what I think we should achieve is to:
1) Reduce the diff between the buildfarm code and the in-core code.
2) Get rid of test.sh.
3) Be able to run easily upgrade tests across major versions for
developers.
As of now, 3) requires some extra facilities depending on if this is
done by the buildfarm or the in-core tests:
1) Path to the source code of the old version. This is required once
it becomes necessary to find out src/test/regress/ for the schedule,
the tests to run and its regress.so. There is no need to do that if
you have a dump of the old instance.
2) Path to a custom dump to replace the run with pg_regress from 1).
3) Location of the old binaries, for pg_upgrade. When it comes to
PostgresNode, we require an install path, so we cannot use directly
the location of the binaries.
Looking at the code of the buildfarm, its code does something smarter
than what my patch or HEAD's test.sh does now, as these require the
path for the old source. The buildfarm code first scans for the
probin's used in the regression database and then updates any
references. What test.sh and my patch do is using the path to the old
source code and run a single UPDATE. The approach taken by the
buildfarm code is more portable, as a path to the old source code
becomes necessary only if running pg_regress manually. So, what about
doing the following thing?
1) Update the TAP test so as probin entries are updated in the same way
as the buildfarm.
2) Allow one to specify a path to a custom dump, or a path to the old
source code for pg_regress.
If we do that, then it should be possible to reduce the code footprint
in the buildfarm code, while still allowing people to test major
upgrades in the same old-fashioned way, right? That's assuming that
PostgresNode is made compatible down to 9.2, of course, as a first
step, as that's the range of the dumps you are keeping around for the
buildfarm.
Thoughts?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2021-05-17 16:32 ` Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andrew Dunstan @ 2021-05-17 16:32 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Postgres hackers <[email protected]>
On 5/16/21 9:55 PM, Michael Paquier wrote:
> On Sat, May 15, 2021 at 02:22:24PM -0400, Andrew Dunstan wrote:
>> PostgresNode is currently able to create nodes suitable for upgrade down
>> to release 10. If we add '-w' to the 'pg_ctl start' flags that can
>> extend down to release 9.5. (Just tested) I think we should do that
>> forthwith. '-w' is now the default, but having it there explicitly does
>> no harm.
> Agreed. When testing manually, I have personally never worked on any
> patches that required binaries older than 9.4, so I would be fine if
> the TAP tests are able to work easily down to 9.5, even if pg_upgrade
> is supported down to 8.4.
>
>> If people are interested in what's incompatible on older versions, they
>> can look at
>> <https://gitlab.com/adunstan/postgresnodeng/-/blob/master/PostgresNode.pm;
>> starting at about line 2764.
> We should really have adjust_conf() at some point in the in-core
> module.
Yes, I'm going to be proposing a series of smallish patches including
these when the tree is branched (which I hope will be in a few weeks).
>> I don't think this will work, though, unless there is enough data to
>> exercise pg_upgrade fairly thoroughly. The approach taken by both
>> test.sh and (somewhat more comprehensively) by the buildfarm cross
>> version upgrade module is to test a cluster where the regression tests
>> have been run.
> Yeah, that's what my patch is doing with pg_regress, FWIW. This
> requires regress.so from the old version.
>
>> That might be more difficult when testing against older
>> versions, so I have published a snapshot of the dumps of each of the
>> versions we tests against in the buildfarm animal crake. These could be
>> loaded into PostgresNode instances and then an upgrade attempted. See
>> <https://gitlab.com/adunstan/pg-old-bin/-/tree/master/data;. The data
>> goes back to 9.2. These compressed dumps are a couple of megabytes each,
>> not huge.
> I agree that this can be simpler in some cases. In your experience,
> how much of an issue is it when it becomes necessary to keep around
> binaries that rely on libraries older than what a system can support?
> It is easy to counter issues in this area with OpenSSL and
> non-necessary things, but we had in the past also cases where we had
> code that conflicted with the kernel, aka 3e68686.
That one at least isn't an issue. Old versions of postgres didn't have
pg_rewind.
>
> At the end of this exercise, what I think we should achieve is to:
> 1) Reduce the diff between the buildfarm code and the in-core code.
> 2) Get rid of test.sh.
> 3) Be able to run easily upgrade tests across major versions for
> developers.
>
> As of now, 3) requires some extra facilities depending on if this is
> done by the buildfarm or the in-core tests:
> 1) Path to the source code of the old version. This is required once
> it becomes necessary to find out src/test/regress/ for the schedule,
> the tests to run and its regress.so. There is no need to do that if
> you have a dump of the old instance.
> 2) Path to a custom dump to replace the run with pg_regress from 1).
> 3) Location of the old binaries, for pg_upgrade. When it comes to
> PostgresNode, we require an install path, so we cannot use directly
> the location of the binaries.
>
> Looking at the code of the buildfarm, its code does something smarter
> than what my patch or HEAD's test.sh does now, as these require the
> path for the old source. The buildfarm code first scans for the
> probin's used in the regression database and then updates any
> references. What test.sh and my patch do is using the path to the old
> source code and run a single UPDATE. The approach taken by the
> buildfarm code is more portable, as a path to the old source code
> becomes necessary only if running pg_regress manually. So, what about
> doing the following thing?
> 1) Update the TAP test so as probin entries are updated in the same way
> as the buildfarm.
> 2) Allow one to specify a path to a custom dump, or a path to the old
> source code for pg_regress.
>
> If we do that, then it should be possible to reduce the code footprint
> in the buildfarm code, while still allowing people to test major
> upgrades in the same old-fashioned way, right? That's assuming that
> PostgresNode is made compatible down to 9.2, of course, as a first
> step, as that's the range of the dumps you are keeping around for the
> buildfarm.
>
I'm intending to add some older dumps. -) But for now 9.2 is a good target.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
@ 2021-05-18 01:49 ` Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2021-05-18 01:49 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Postgres hackers <[email protected]>
On Mon, May 17, 2021 at 12:32:13PM -0400, Andrew Dunstan wrote:
> On 5/16/21 9:55 PM, Michael Paquier wrote:
> Yes, I'm going to be proposing a series of smallish patches including
> these when the tree is branched (which I hope will be in a few weeks).
Thanks! That clearly needs to happen first. I'll help reviewing
these.
>> If we do that, then it should be possible to reduce the code footprint
>> in the buildfarm code, while still allowing people to test major
>> upgrades in the same old-fashioned way, right? That's assuming that
>> PostgresNode is made compatible down to 9.2, of course, as a first
>> step, as that's the range of the dumps you are keeping around for the
>> buildfarm.
>
> I'm intending to add some older dumps. -) But for now 9.2 is a good target.
Makes sense. For now, I'll update this patch set so as it is possible
to use custom dumps, as an option in parallel of pg_regress when
specifying a different source code path. I'll also decouple the
business with probin updates and stick with the approach used by the
buildfarm code.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2021-05-20 06:07 ` Michael Paquier <[email protected]>
2021-09-07 21:43 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Rachel Heaton <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 2 replies; 118+ messages in thread
From: Michael Paquier @ 2021-05-20 06:07 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Postgres hackers <[email protected]>
On Tue, May 18, 2021 at 10:49:39AM +0900, Michael Paquier wrote:
> Makes sense. For now, I'll update this patch set so as it is possible
> to use custom dumps, as an option in parallel of pg_regress when
> specifying a different source code path. I'll also decouple the
> business with probin updates and stick with the approach used by the
> buildfarm code.
This has proved to not be that difficult. With the updated version
attached, pg_upgrade has two modes to set up the old instance used for
the upgrade with older binaries:
- With oldsrc and oldinstall set, pg_regress gets used, same way as
HEAD.
- With olddump and oldinstall set, an old dump is loaded instead in
the old instance before launching the upgrade.
oldsrc and olddump are exclusive options. Similarly to HEAD, the
dumps taken from the old and new instances generate diffs that can be
inspected manually. The updates of probin are done without any
dependencies to the source path of the old instance, copying from the
buildfarm.
While on it, I have fixed a couple of things that exist in test.sh but
were not reflected in this new script:
- Handling of postfix operations with ~13 clusters.
- Handling oldstyle_length for ~9.6 clusters.
- Handling of EXTRA_REGRESS_OPT.
This stuff still needs to be expanded depending on how PostgresNode is
made backward-compatible, but I'll wait for that to happen before
going further down here. I have also spent some time testing all that
with MSVC, and the installation paths used for pg_regress&co make the
script a tad more confusing, so I have dropped this part for now.
Thanks,
--
Michael
Attachments:
[text/x-diff] v2-0001-Switch-tests-of-pg_upgrade-to-use-TAP.patch (22.8K, ../../[email protected]/2-v2-0001-Switch-tests-of-pg_upgrade-to-use-TAP.patch)
download | inline diff:
From bfb0086cfc35c063acc671896a7ffcb2c23dc2c2 Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email protected]>
Date: Thu, 20 May 2021 15:04:55 +0900
Subject: [PATCH v2] Switch tests of pg_upgrade to use TAP
---
src/bin/pg_upgrade/Makefile | 17 +-
src/bin/pg_upgrade/TESTING | 29 ++-
src/bin/pg_upgrade/t/001_basic.pl | 9 +
src/bin/pg_upgrade/t/002_pg_upgrade.pl | 266 ++++++++++++++++++++++++
src/bin/pg_upgrade/test.sh | 272 -------------------------
src/test/perl/PostgresNode.pm | 25 +++
6 files changed, 323 insertions(+), 295 deletions(-)
create mode 100644 src/bin/pg_upgrade/t/001_basic.pl
create mode 100644 src/bin/pg_upgrade/t/002_pg_upgrade.pl
delete mode 100644 src/bin/pg_upgrade/test.sh
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 44d06be5a6..fa8dee0a9c 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -49,17 +49,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-# When $(MAKE) is present, make automatically infers that this is a
-# recursive make. which is not actually what we want here, as that
-# e.g. prevents output synchronization from working (as make thinks
-# that the subsidiary make knows how to deal with that itself, but
-# we're invoking a shell script that doesn't know). Referencing
-# $(MAKE) indirectly avoids that behaviour.
-# See https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable
-NOTSUBMAKEMAKE=$(MAKE)
+check:
+ $(prove_check)
-check: test.sh all temp-install
- MAKE=$(NOTSUBMAKEMAKE) $(with_temp_install) bindir=$(abs_top_builddir)/tmp_install/$(bindir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $<
-
-# installcheck is not supported because there's no meaningful way to test
-# pg_upgrade against a single already-running server
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
index e69874b42d..185943dd4b 100644
--- a/src/bin/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -4,19 +4,26 @@ 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.
+in this directory. 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.
-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:
+To test an upgrade from a different version, there are two options
+available:
+
+1) You have a built source tree for the old version as well as this
+version's binaries. Then set up the following variables:
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
+export oldinstall=...otherversion/bin (old version's install base path)
+
+2) You have a dump that can be used to set up the old version, as well
+as this version's binaries. Then set up the following variables:
+export olddump=...somewhere/dump.sql (old version's dump)
+export oldinstall=...otherversion/bin (old version's install base path)
+
+Finally, the tests can be done by running
+ make check
In this case, you will have to manually eyeball the resulting dump
diff for version-specific differences, as explained below.
@@ -87,3 +94,5 @@ steps:
7) Diff the regression database dump file with the regression dump
file loaded into the old server.
+
+The generated dump may be reusable with "olddump", as defined above.
diff --git a/src/bin/pg_upgrade/t/001_basic.pl b/src/bin/pg_upgrade/t/001_basic.pl
new file mode 100644
index 0000000000..605a7f622f
--- /dev/null
+++ b/src/bin/pg_upgrade/t/001_basic.pl
@@ -0,0 +1,9 @@
+use strict;
+use warnings;
+
+use TestLib;
+use Test::More tests => 8;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
new file mode 100644
index 0000000000..4d813ad5c3
--- /dev/null
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -0,0 +1,266 @@
+# Set of tests for pg_upgrade.
+use strict;
+use warnings;
+
+use Cwd qw(abs_path getcwd);
+use File::Basename qw(dirname);
+
+use PostgresNode;
+use TestLib;
+use Test::More tests => 4;
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log([ 'createdb', '--port', $node->port, $dbname ]);
+}
+
+my $startdir = getcwd();
+
+# From now on, the test of pg_upgrade consists in setting up an instance.
+# This is the source instance used for the upgrade. Then a new and fresh
+# instance is created, and is used as the target instance for the
+# upgrade. Before running an upgrade a logical dump of the old instance
+# is taken, and a second logical dump of the new instance is taken after
+# the upgrade. The upgrade test passes if there are no differences after
+# running pg_upgrade.
+
+# Testing upgrades with an older instance of PostgreSQL requires
+# setting up two environment variables, among the following:
+# - "oldsrc", to point to the code source of the older version.
+# This is required to set up the old instance with pg_upgrade.
+# - "olddump", to point to a dump file that will be used to set
+# up the old instance to upgrade from.
+# - "oldinstall", to point to the installation path of the older
+# version.
+
+# "oldsrc" and "olddump" cannot be used together. Setting up
+# "olddump" and "oldinstall" will use the dump pointed to to
+# set up the old instance. If "oldsrc" is used instead of "olddump",
+# the full set of regression tests of the old instance is run
+# instead.
+
+if (defined($ENV{oldsrc}) && defined($ENV{olddump}))
+{
+ die "oldsrc and olddump are both defined";
+}
+elsif (defined($ENV{oldsrc}))
+{
+ if ( (defined($ENV{oldsrc}) && !defined($ENV{oldinstall}))
+ || (!defined($ENV{oldsrc}) && defined($ENV{oldinstall})))
+ {
+ # Not all variables are defined, so leave and die if test is
+ # done with an older installation.
+ die "oldsrc or oldinstall is undefined";
+ }
+}
+elsif (defined($ENV{olddump}))
+{
+ if ( (defined($ENV{olddump}) && !defined($ENV{oldinstall}))
+ || (!defined($ENV{olddump}) && defined($ENV{oldinstall})))
+ {
+ # Not all variables are defined, so leave and die if test is
+ # done with an older installation.
+ die "olddump or oldinstall is undefined";
+ }
+}
+
+if ((defined($ENV{oldsrc}) || defined($ENV{olddump})) && $windows_os)
+{
+ # This configuration is not supported on Windows, as regress.so
+ # location diverges across the compilation methods used on this
+ # platform.
+ die "No support for older version tests on Windows";
+}
+
+# Default is the location of this source code for both nodes used with
+# the upgrade.
+my $newsrc = abs_path("../../..");
+my $oldsrc = $ENV{oldsrc} || $newsrc;
+$oldsrc = abs_path($oldsrc);
+
+# Temporary location for the dumps taken
+my $tempdir = TestLib::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = get_new_node('old_node', install_path => $ENV{oldinstall});
+
+$oldnode->init(extra => [ '--locale', 'C', '--encoding', 'LATIN1' ]);
+$oldnode->start;
+
+# Set up the data of the old instance with pg_regress or an old dump.
+if (defined($ENV{olddump}))
+{
+ # Use the dump specified.
+ my $olddumpfile = $ENV{olddump};
+ die "no dump file found!" unless -e $olddumpfile;
+
+ # Load the dump, and we are done here.
+ $oldnode->command_ok(
+ [ 'psql', '-f', $olddumpfile, '--port', $oldnode->port, 'postgres' ]);
+}
+else
+{
+ # Default is to just use pg_regress to setup the old instance
+ # Creating databases with names covering most ASCII bytes
+ generate_db($oldnode, 1, 45);
+ generate_db($oldnode, 46, 90);
+ generate_db($oldnode, 91, 127);
+
+ # Run core regression tests on the old instance.
+ $oldnode->run_log([ "createdb", '--port', $oldnode->port, 'regression' ]);
+
+ # This is more a trick than anything else, as pg_regress needs to be
+ # from the old instance. --dlpath is needed to be able to find the
+ # location of regress.so, and it is located in the same folder as
+ # pg_regress itself.
+
+ # Grab any regression options that may be passed down by caller.
+ my $extra_opts_val = $ENV{EXTRA_REGRESS_OPT} || "";
+ my @extra_opts = split(/\s+/, $extra_opts_val);
+
+ chdir "$oldsrc/src/test/regress/";
+ my @regress_command = [
+ $ENV{PG_REGRESS}, '--schedule',
+ 'parallel_schedule', '--bindir',
+ $oldnode->config_data('--bindir'), '--make-testtablespace-dir',
+ '--dlpath', '.',
+ '--use-existing', '--port',
+ $oldnode->port
+ ];
+ @regress_command = (@regress_command, @extra_opts);
+
+ $oldnode->command_ok(@regress_command,
+ 'regression test run on old instance');
+
+ # Move back to the start path.
+ chdir $startdir;
+}
+
+# Before dumping, get rid of objects not existing or not supported in later
+# versions. This depends on the version of the old server used, and matters
+# only if different versions are used for the dump.
+my ($result, $oldpgversion, $stderr) =
+ $oldnode->psql('postgres', qq[SHOW server_version_num;]);
+my $fix_sql;
+
+if (defined($ENV{oldinstall}))
+{
+ # Changes for PostgreSQL ~13
+ if ($oldpgversion < 140000)
+ {
+ # Postfix operators are not supported anymore in 14.
+ $oldnode->psql(
+ 'regression', "
+ DROP OPERATOR IF EXISTS #@# (bigint,NONE);
+ DROP OPERATOR IF EXISTS #%# (bigint,NONE);
+ DROP OPERATOR IF EXISTS !=- (bigint,NONE);
+ DROP OPERATOR IF EXISTS #@%# (bigint,NONE);");
+ # Last appeared in 13.
+ $oldnode->psql('regression', "DROP FUNCTION public.putenv(text);");
+ }
+
+ # Changes for PostgreSQL ~9.6
+ if ($oldpgversion < 100000)
+ {
+ # Last appeared in 9.6.
+ $oldnode->psql('regression',
+ "DROP FUNCTION public.oldstyle_length(integer, text);");
+ }
+
+ # Add here tweaks to objects to adapt to newer versions.
+}
+
+# Initialize a new node for the upgrade. This is done early so as it is
+# possible to know with which node's PATH the initial dump needs to be
+# taken.
+my $newnode = get_new_node('new_node');
+$newnode->init(extra => [ '--locale=C', '--encoding=LATIN1' ]);
+my $newbindir = $newnode->config_data('--bindir');
+my $oldbindir = $oldnode->config_data('--bindir');
+
+# Take a dump before performing the upgrade as a base comparison. Note
+# that we need to use pg_dumpall from the new node here.
+$newnode->command_ok(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $oldnode->connstr('postgres'),
+ '-f', "$tempdir/dump1.sql"
+ ],
+ 'dump before running pg_upgrade');
+
+# After dumping, update references to the old source tree's regress.so
+# to point to the new tree.
+if (defined($ENV{oldinstall}))
+{
+ # First, fetch all the references to libraries that are not part
+ # of the default path $libdir.
+ my $output = $oldnode->safe_psql('regression',
+ "SELECT probin::text from pg_proc where probin not like '\$libdir%';"
+ );
+ chomp($output);
+ my @libpaths = split("\n", $output);
+
+ my $dump_data = slurp_file("$tempdir/dump1.sql");
+
+ my $newregresssrc = "$newsrc/src/test/regress";
+ foreach (@libpaths)
+ {
+ my $libpath = $_;
+ $libpath = dirname($libpath);
+ $dump_data =~ s/$libpath/$newregresssrc/g;
+ }
+
+ open my $fh, ">", "$tempdir/dump1.sql" or die "could not open dump file";
+ print $fh $dump_data;
+ close $fh;
+
+ # This replaces any references to the old tree's regress.so
+ # the new tree's regress.so. Any references that do *not*
+ # match $libdir are switched so as this request does not
+ # depend on the path of the old source tree. This is useful
+ # when using an old dump.
+ $oldnode->safe_psql(
+ 'regression', "UPDATE pg_proc SET probin =
+ regexp_replace(probin, '.*/', '$newregresssrc/')
+ WHERE probin NOT LIKE '\$libdir/%'");
+}
+
+# Move back to current directory, all logs generated need to be located
+# at the origin.
+chdir $startdir;
+
+# Update the instance.
+$oldnode->stop;
+
+# Time for the real run.
+chdir "$newsrc/src/test/regress";
+$newnode->command_ok(
+ [
+ 'pg_upgrade', '-d', $oldnode->data_dir, '-D',
+ $newnode->data_dir, '-b', $oldbindir, '-B',
+ $newbindir, '-p', $oldnode->port, '-P',
+ $newnode->port
+ ],
+ 'run of pg_upgrade for new instance');
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+$newnode->run_log(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $newnode->connstr('postgres'),
+ '-f', "$tempdir/dump2.sql"
+ ]);
+
+# Compare the two dumps, there should be no differences.
+command_ok([ 'diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql" ],
+ 'Old and new dump match after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index 1ba326decd..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,272 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2021, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- # To increase coverage of non-standard segment size and group access
- # without increasing test runtime, run these tests with a custom setting.
- # Also, specify "-A trust" explicitly to suppress initdb's warning.
- "$1" -N --wal-segsize 1 -g -A trust
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# What flavor of host are we on?
-# Treat MINGW* (msys1) and MSYS* (msys2) the same.
-testhost=`uname -s | sed 's/^MSYS/MINGW/'`
-
-# Establish how the server will listen for connections
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PG_REGRESS_SOCKET_DIR=""
- PGHOST=localhost
- ;;
- *)
- LISTEN_ADDRESSES=""
- # Select a socket directory. The algorithm is from the "configure"
- # script; the outcome mimics pg_regress.c:make_temp_sockdir().
- if [ x"$PG_REGRESS_SOCKET_DIR" = x ]; then
- set +e
- dir=`(umask 077 &&
- mktemp -d /tmp/pg_upgrade_check-XXXXXX) 2>/dev/null`
- if [ ! -d "$dir" ]; then
- dir=/tmp/pg_upgrade_check-$$-$RANDOM
- (umask 077 && mkdir "$dir")
- if [ ! -d "$dir" ]; then
- echo "could not create socket temporary directory in \"/tmp\""
- exit 1
- fi
- fi
- set -e
- PG_REGRESS_SOCKET_DIR=$dir
- trap 'rm -rf "$PG_REGRESS_SOCKET_DIR"' 0
- trap 'exit 3' 1 2 13 15
- fi
- PGHOST=$PG_REGRESS_SOCKET_DIR
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=\"$LISTEN_ADDRESSES\" -k \"$PG_REGRESS_SOCKET_DIR\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-temp_root=`pwd`/tmp_check
-rm -rf "$temp_root"
-mkdir "$temp_root"
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-# We need to make pg_regress use psql from the desired installation
-# (likely a temporary one), because otherwise the installcheck run
-# below would try to use psql from the proper installation directory
-# of the target version, which might be outdated or not exist. But
-# don't override anything else that's already in EXTRA_REGRESS_OPTS.
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$oldbindir'"
-export EXTRA_REGRESS_OPTS
-
-# While in normal cases this will already be set up, adding bindir to
-# path allows test.sh to be invoked with different versions as
-# described in ./TESTING
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA="$temp_root/data"
-PGDATA="${BASE_PGDATA}.old"
-export PGDATA
-
-# Send installcheck outputs to a private directory. This avoids conflict when
-# check-world runs pg_upgrade check concurrently with src/test/regress check.
-# To retrieve interesting files after a run, use pattern tmp_check/*/*.diffs.
-outputdir="$temp_root/regress"
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --outputdir=$outputdir"
-export EXTRA_REGRESS_OPTS
-mkdir "$outputdir"
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "regression$dbname1" || createdb_status=$?
-createdb "regression$dbname2" || createdb_status=$?
-createdb "regression$dbname3" || createdb_status=$?
-
-if "$MAKE" -C "$oldsrc" installcheck-parallel; then
- oldpgversion=`psql -X -A -t -d regression -c "SHOW server_version_num"`
-
- # before dumping, get rid of objects not feasible in later versions
- if [ "$newsrc" != "$oldsrc" ]; then
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="DROP FUNCTION public.myfunc(integer);"
- ;;
- esac
- fix_sql="$fix_sql
- DROP FUNCTION IF EXISTS
- public.oldstyle_length(integer, text); -- last in 9.6
- DROP FUNCTION IF EXISTS
- public.putenv(text); -- last in v13
- DROP OPERATOR IF EXISTS -- last in v13
- public.#@# (pg_catalog.int8, NONE),
- public.#%# (pg_catalog.int8, NONE),
- public.!=- (pg_catalog.int8, NONE),
- public.#@%# (pg_catalog.int8, NONE);"
- psql -X -d regression -c "$fix_sql;" || psql_fix_sql_status=$?
- fi
-
- pg_dumpall --no-sync -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
-
- if [ "$newsrc" != "$oldsrc" ]; then
- # update references to old source tree's regress.so etc
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%';"
- ;;
- *)
- fix_sql="UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';"
- ;;
- esac
- psql -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA="$BASE_PGDATA"
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "$PGDATA" -b "$oldbindir" -p "$PGPORT" -P "$PGPORT"
-
-# make sure all directories and files have group permissions, on Unix hosts
-# Windows hosts don't support Unix-y permissions.
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type f ! -perm 640 | wc -l` -ne 0 ]; then
- echo "files in PGDATA with permission != 640";
- exit 1;
- fi ;;
-esac
-
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type d ! -perm 750 | wc -l` -ne 0 ]; then
- echo "directories in PGDATA with permission != 750";
- exit 1;
- fi ;;
-esac
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-pg_dumpall --no-sync -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) MSYS2_ARG_CONV_EXCL=/c cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm
index f7088667a4..31ddbdfa4a 100644
--- a/src/test/perl/PostgresNode.pm
+++ b/src/test/perl/PostgresNode.pm
@@ -340,6 +340,31 @@ sub backup_dir
=pod
+=item $node->config_data($option)
+
+Grab some data from pg_config, with $option being the switched
+used.
+
+=cut
+
+sub config_data
+{
+ my ($self, $option) = @_;
+ local %ENV = $self->_get_env();
+
+ my ($stdout, $stderr);
+ my $result =
+ IPC::Run::run [ $self->installed_command('pg_config'), $option ],
+ '>', \$stdout, '2>', \$stderr
+ or die "could not execute pg_config";
+ chomp($stdout);
+ $stdout =~ s/\r$//;
+
+ return $stdout;
+}
+
+=pod
+
=item $node->info()
Return a string containing human-readable diagnostic information (paths, etc)
--
2.31.1
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2021-09-07 21:43 ` Rachel Heaton <[email protected]>
2021-09-08 06:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Rachel Heaton @ 2021-09-07 21:43 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
Hello Michael,
This patch needs the update from 201a76183 -- the function `get_new_node`
no longer exists.
Running check tests in the pg_upgrade folder fails for this reason.
Thank you,
Rachel
On Tue, Sep 7, 2021 at 2:06 PM Michael Paquier <[email protected]> wrote:
> On Tue, May 18, 2021 at 10:49:39AM +0900, Michael Paquier wrote:
> > Makes sense. For now, I'll update this patch set so as it is possible
> > to use custom dumps, as an option in parallel of pg_regress when
> > specifying a different source code path. I'll also decouple the
> > business with probin updates and stick with the approach used by the
> > buildfarm code.
>
> This has proved to not be that difficult. With the updated version
> attached, pg_upgrade has two modes to set up the old instance used for
> the upgrade with older binaries:
> - With oldsrc and oldinstall set, pg_regress gets used, same way as
> HEAD.
> - With olddump and oldinstall set, an old dump is loaded instead in
> the old instance before launching the upgrade.
>
> oldsrc and olddump are exclusive options. Similarly to HEAD, the
> dumps taken from the old and new instances generate diffs that can be
> inspected manually. The updates of probin are done without any
> dependencies to the source path of the old instance, copying from the
> buildfarm.
>
> While on it, I have fixed a couple of things that exist in test.sh but
> were not reflected in this new script:
> - Handling of postfix operations with ~13 clusters.
> - Handling oldstyle_length for ~9.6 clusters.
> - Handling of EXTRA_REGRESS_OPT.
>
> This stuff still needs to be expanded depending on how PostgresNode is
> made backward-compatible, but I'll wait for that to happen before
> going further down here. I have also spent some time testing all that
> with MSVC, and the installation paths used for pg_regress&co make the
> script a tad more confusing, so I have dropped this part for now.
>
> Thanks,
> --
> Michael
>
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-09-07 21:43 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Rachel Heaton <[email protected]>
@ 2021-09-08 06:34 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2021-09-08 06:34 UTC (permalink / raw)
To: Rachel Heaton <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Tue, Sep 07, 2021 at 02:43:15PM -0700, Rachel Heaton wrote:
> Running check tests in the pg_upgrade folder fails for this reason.
Thanks, rebased as attached. Andrew has posted another patch set that
completely reworks the shape of the modules by moving them into a
dedicated namespace, meaning that this is going to break again. I'll
see about that when we reach this point.
--
Michael
From 6580f1b9bcf12a2b65e90f355ecf10250c121603 Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email protected]>
Date: Wed, 8 Sep 2021 15:30:57 +0900
Subject: [PATCH v3] Switch tests of pg_upgrade to use TAP
---
src/bin/pg_upgrade/Makefile | 17 +-
src/bin/pg_upgrade/TESTING | 29 ++-
src/bin/pg_upgrade/t/001_basic.pl | 9 +
src/bin/pg_upgrade/t/002_pg_upgrade.pl | 277 +++++++++++++++++++++++++
src/bin/pg_upgrade/test.sh | 272 ------------------------
src/test/perl/PostgresNode.pm | 25 +++
6 files changed, 334 insertions(+), 295 deletions(-)
create mode 100644 src/bin/pg_upgrade/t/001_basic.pl
create mode 100644 src/bin/pg_upgrade/t/002_pg_upgrade.pl
delete mode 100644 src/bin/pg_upgrade/test.sh
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 44d06be5a6..fa8dee0a9c 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -49,17 +49,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-# When $(MAKE) is present, make automatically infers that this is a
-# recursive make. which is not actually what we want here, as that
-# e.g. prevents output synchronization from working (as make thinks
-# that the subsidiary make knows how to deal with that itself, but
-# we're invoking a shell script that doesn't know). Referencing
-# $(MAKE) indirectly avoids that behaviour.
-# See https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable
-NOTSUBMAKEMAKE=$(MAKE)
+check:
+ $(prove_check)
-check: test.sh all temp-install
- MAKE=$(NOTSUBMAKEMAKE) $(with_temp_install) bindir=$(abs_top_builddir)/tmp_install/$(bindir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $<
-
-# installcheck is not supported because there's no meaningful way to test
-# pg_upgrade against a single already-running server
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
index e69874b42d..185943dd4b 100644
--- a/src/bin/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -4,19 +4,26 @@ 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.
+in this directory. 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.
-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:
+To test an upgrade from a different version, there are two options
+available:
+
+1) You have a built source tree for the old version as well as this
+version's binaries. Then set up the following variables:
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
+export oldinstall=...otherversion/bin (old version's install base path)
+
+2) You have a dump that can be used to set up the old version, as well
+as this version's binaries. Then set up the following variables:
+export olddump=...somewhere/dump.sql (old version's dump)
+export oldinstall=...otherversion/bin (old version's install base path)
+
+Finally, the tests can be done by running
+ make check
In this case, you will have to manually eyeball the resulting dump
diff for version-specific differences, as explained below.
@@ -87,3 +94,5 @@ steps:
7) Diff the regression database dump file with the regression dump
file loaded into the old server.
+
+The generated dump may be reusable with "olddump", as defined above.
diff --git a/src/bin/pg_upgrade/t/001_basic.pl b/src/bin/pg_upgrade/t/001_basic.pl
new file mode 100644
index 0000000000..605a7f622f
--- /dev/null
+++ b/src/bin/pg_upgrade/t/001_basic.pl
@@ -0,0 +1,9 @@
+use strict;
+use warnings;
+
+use TestLib;
+use Test::More tests => 8;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
new file mode 100644
index 0000000000..0bdbe6dc26
--- /dev/null
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -0,0 +1,277 @@
+# Set of tests for pg_upgrade.
+use strict;
+use warnings;
+
+use Cwd qw(abs_path getcwd);
+use File::Basename qw(dirname);
+
+use PostgresNode;
+use TestLib;
+use Test::More tests => 4;
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log([ 'createdb', '--port', $node->port, $dbname ]);
+}
+
+my $startdir = getcwd();
+
+# From now on, the test of pg_upgrade consists in setting up an instance.
+# This is the source instance used for the upgrade. Then a new and fresh
+# instance is created, and is used as the target instance for the
+# upgrade. Before running an upgrade a logical dump of the old instance
+# is taken, and a second logical dump of the new instance is taken after
+# the upgrade. The upgrade test passes if there are no differences after
+# running pg_upgrade.
+
+# Testing upgrades with an older instance of PostgreSQL requires
+# setting up two environment variables, among the following:
+# - "oldsrc", to point to the code source of the older version.
+# This is required to set up the old instance with pg_upgrade.
+# - "olddump", to point to a dump file that will be used to set
+# up the old instance to upgrade from.
+# - "oldinstall", to point to the installation path of the older
+# version.
+
+# "oldsrc" and "olddump" cannot be used together. Setting up
+# "olddump" and "oldinstall" will use the dump pointed to to
+# set up the old instance. If "oldsrc" is used instead of "olddump",
+# the full set of regression tests of the old instance is run
+# instead.
+
+if (defined($ENV{oldsrc}) && defined($ENV{olddump}))
+{
+ die "oldsrc and olddump are both defined";
+}
+elsif (defined($ENV{oldsrc}))
+{
+ if ( (defined($ENV{oldsrc}) && !defined($ENV{oldinstall}))
+ || (!defined($ENV{oldsrc}) && defined($ENV{oldinstall})))
+ {
+ # Not all variables are defined, so leave and die if test is
+ # done with an older installation.
+ die "oldsrc or oldinstall is undefined";
+ }
+}
+elsif (defined($ENV{olddump}))
+{
+ if ( (defined($ENV{olddump}) && !defined($ENV{oldinstall}))
+ || (!defined($ENV{olddump}) && defined($ENV{oldinstall})))
+ {
+ # Not all variables are defined, so leave and die if test is
+ # done with an older installation.
+ die "olddump or oldinstall is undefined";
+ }
+}
+
+if ((defined($ENV{oldsrc}) || defined($ENV{olddump})) && $windows_os)
+{
+ # This configuration is not supported on Windows, as regress.so
+ # location diverges across the compilation methods used on this
+ # platform.
+ die "No support for older version tests on Windows";
+}
+
+# Default is the location of this source code for both nodes used with
+# the upgrade.
+my $newsrc = abs_path("../../..");
+my $oldsrc = $ENV{oldsrc} || $newsrc;
+$oldsrc = abs_path($oldsrc);
+
+# Temporary location for the dumps taken
+my $tempdir = TestLib::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = PostgresNode->new('old_node', install_path => $ENV{oldinstall});
+
+$oldnode->init(extra => [ '--locale', 'C', '--encoding', 'LATIN1' ]);
+$oldnode->start;
+
+# Set up the data of the old instance with pg_regress or an old dump.
+if (defined($ENV{olddump}))
+{
+ # Use the dump specified.
+ my $olddumpfile = $ENV{olddump};
+ die "no dump file found!" unless -e $olddumpfile;
+
+ # Load the dump, and we are done here.
+ $oldnode->command_ok(
+ [ 'psql', '-f', $olddumpfile, '--port', $oldnode->port, 'postgres' ]);
+}
+else
+{
+ # Default is to just use pg_regress to setup the old instance
+ # Creating databases with names covering most ASCII bytes
+ generate_db($oldnode, 1, 45);
+ generate_db($oldnode, 46, 90);
+ generate_db($oldnode, 91, 127);
+
+ # Run core regression tests on the old instance.
+ $oldnode->run_log([ "createdb", '--port', $oldnode->port, 'regression' ]);
+
+ # This is more a trick than anything else, as pg_regress needs to be
+ # from the old instance. --dlpath is needed to be able to find the
+ # location of regress.so, and it is located in the same folder as
+ # pg_regress itself.
+
+ # Grab any regression options that may be passed down by caller.
+ my $extra_opts_val = $ENV{EXTRA_REGRESS_OPT} || "";
+ my @extra_opts = split(/\s+/, $extra_opts_val);
+
+ chdir "$oldsrc/src/test/regress/";
+ my @regress_command = [
+ $ENV{PG_REGRESS}, '--schedule',
+ 'parallel_schedule', '--bindir',
+ $oldnode->config_data('--bindir'), '--make-testtablespace-dir',
+ '--dlpath', '.',
+ '--use-existing', '--port',
+ $oldnode->port
+ ];
+ @regress_command = (@regress_command, @extra_opts);
+
+ $oldnode->command_ok(@regress_command,
+ 'regression test run on old instance');
+
+ # Move back to the start path.
+ chdir $startdir;
+}
+
+# Before dumping, get rid of objects not existing or not supported in later
+# versions. This depends on the version of the old server used, and matters
+# only if different versions are used for the dump.
+my ($result, $oldpgversion, $stderr) =
+ $oldnode->psql('postgres', qq[SHOW server_version_num;]);
+my $fix_sql;
+
+if (defined($ENV{oldinstall}))
+{
+ # Changes for PostgreSQL ~13
+ if ($oldpgversion < 140000)
+ {
+ # Postfix operators are not supported anymore in 14.
+ $oldnode->psql(
+ 'regression', "
+ DROP OPERATOR IF EXISTS #@# (bigint,NONE);
+ DROP OPERATOR IF EXISTS #%# (bigint,NONE);
+ DROP OPERATOR IF EXISTS !=- (bigint,NONE);
+ DROP OPERATOR IF EXISTS #@%# (bigint,NONE);");
+ # Last appeared in 13.
+ $oldnode->psql('regression', "DROP FUNCTION public.putenv(text);");
+ }
+
+ # Changes for PostgreSQL ~9.6
+ if ($oldpgversion < 100000)
+ {
+ # Last appeared in 9.6.
+ $oldnode->psql('regression',
+ "DROP FUNCTION public.oldstyle_length(integer, text);");
+ }
+
+ # Add here tweaks to objects to adapt to newer versions.
+}
+
+# Initialize a new node for the upgrade. This is done early so as it is
+# possible to know with which node's PATH the initial dump needs to be
+# taken.
+my $newnode = PostgresNode->new('new_node');
+$newnode->init(extra => [ '--locale=C', '--encoding=LATIN1' ]);
+my $newbindir = $newnode->config_data('--bindir');
+my $oldbindir = $oldnode->config_data('--bindir');
+
+# Take a dump before performing the upgrade as a base comparison. Note
+# that we need to use pg_dumpall from the new node here.
+$newnode->command_ok(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $oldnode->connstr('postgres'),
+ '-f', "$tempdir/dump1.sql"
+ ],
+ 'dump before running pg_upgrade');
+
+# After dumping, update references to the old source tree's regress.so
+# to point to the new tree.
+if (defined($ENV{oldinstall}))
+{
+ # First, fetch all the references to libraries that are not part
+ # of the default path $libdir.
+ my $output = $oldnode->safe_psql('regression',
+ "SELECT DISTINCT probin::text FROM pg_proc WHERE probin NOT LIKE '\$libdir%';"
+ );
+ chomp($output);
+ my @libpaths = split("\n", $output);
+
+ my $dump_data = slurp_file("$tempdir/dump1.sql");
+
+ my $newregresssrc = "$newsrc/src/test/regress";
+ foreach (@libpaths)
+ {
+ my $libpath = $_;
+ $libpath = dirname($libpath);
+ $dump_data =~ s/$libpath/$newregresssrc/g;
+ }
+
+ open my $fh, ">", "$tempdir/dump1.sql" or die "could not open dump file";
+ print $fh $dump_data;
+ close $fh;
+
+ # This replaces any references to the old tree's regress.so
+ # the new tree's regress.so. Any references that do *not*
+ # match $libdir are switched so as this request does not
+ # depend on the path of the old source tree. This is useful
+ # when using an old dump. Do the operation on all the database
+ # that allow connections so as this includes the regression
+ # database and anything the user has set up.
+ $output = $oldnode->safe_psql('postgres',
+ "SELECT datname FROM pg_database WHERE datallowconn;"
+ );
+ chomp($output);
+ my @datnames = split("\n", $output);
+ foreach (@datnames)
+ {
+ my $datname = $_;
+ $oldnode->safe_psql(
+ $datname, "UPDATE pg_proc SET probin =
+ regexp_replace(probin, '.*/', '$newregresssrc/')
+ WHERE probin NOT LIKE '\$libdir/%'");
+ }
+}
+
+# Move back to current directory, all logs generated need to be located
+# at the origin.
+chdir $startdir;
+
+# Update the instance.
+$oldnode->stop;
+
+# Time for the real run.
+chdir "$newsrc/src/test/regress";
+$newnode->command_ok(
+ [
+ 'pg_upgrade', '-d', $oldnode->data_dir, '-D',
+ $newnode->data_dir, '-b', $oldbindir, '-B',
+ $newbindir, '-p', $oldnode->port, '-P',
+ $newnode->port
+ ],
+ 'run of pg_upgrade for new instance');
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+$newnode->run_log(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $newnode->connstr('postgres'),
+ '-f', "$tempdir/dump2.sql"
+ ]);
+
+# Compare the two dumps, there should be no differences.
+command_ok([ 'diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql" ],
+ 'Old and new dump match after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index 1ba326decd..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,272 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2021, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- # To increase coverage of non-standard segment size and group access
- # without increasing test runtime, run these tests with a custom setting.
- # Also, specify "-A trust" explicitly to suppress initdb's warning.
- "$1" -N --wal-segsize 1 -g -A trust
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# What flavor of host are we on?
-# Treat MINGW* (msys1) and MSYS* (msys2) the same.
-testhost=`uname -s | sed 's/^MSYS/MINGW/'`
-
-# Establish how the server will listen for connections
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PG_REGRESS_SOCKET_DIR=""
- PGHOST=localhost
- ;;
- *)
- LISTEN_ADDRESSES=""
- # Select a socket directory. The algorithm is from the "configure"
- # script; the outcome mimics pg_regress.c:make_temp_sockdir().
- if [ x"$PG_REGRESS_SOCKET_DIR" = x ]; then
- set +e
- dir=`(umask 077 &&
- mktemp -d /tmp/pg_upgrade_check-XXXXXX) 2>/dev/null`
- if [ ! -d "$dir" ]; then
- dir=/tmp/pg_upgrade_check-$$-$RANDOM
- (umask 077 && mkdir "$dir")
- if [ ! -d "$dir" ]; then
- echo "could not create socket temporary directory in \"/tmp\""
- exit 1
- fi
- fi
- set -e
- PG_REGRESS_SOCKET_DIR=$dir
- trap 'rm -rf "$PG_REGRESS_SOCKET_DIR"' 0
- trap 'exit 3' 1 2 13 15
- fi
- PGHOST=$PG_REGRESS_SOCKET_DIR
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=\"$LISTEN_ADDRESSES\" -k \"$PG_REGRESS_SOCKET_DIR\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-temp_root=`pwd`/tmp_check
-rm -rf "$temp_root"
-mkdir "$temp_root"
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-# We need to make pg_regress use psql from the desired installation
-# (likely a temporary one), because otherwise the installcheck run
-# below would try to use psql from the proper installation directory
-# of the target version, which might be outdated or not exist. But
-# don't override anything else that's already in EXTRA_REGRESS_OPTS.
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$oldbindir'"
-export EXTRA_REGRESS_OPTS
-
-# While in normal cases this will already be set up, adding bindir to
-# path allows test.sh to be invoked with different versions as
-# described in ./TESTING
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA="$temp_root/data"
-PGDATA="${BASE_PGDATA}.old"
-export PGDATA
-
-# Send installcheck outputs to a private directory. This avoids conflict when
-# check-world runs pg_upgrade check concurrently with src/test/regress check.
-# To retrieve interesting files after a run, use pattern tmp_check/*/*.diffs.
-outputdir="$temp_root/regress"
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --outputdir=$outputdir"
-export EXTRA_REGRESS_OPTS
-mkdir "$outputdir"
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "regression$dbname1" || createdb_status=$?
-createdb "regression$dbname2" || createdb_status=$?
-createdb "regression$dbname3" || createdb_status=$?
-
-if "$MAKE" -C "$oldsrc" installcheck-parallel; then
- oldpgversion=`psql -X -A -t -d regression -c "SHOW server_version_num"`
-
- # before dumping, get rid of objects not feasible in later versions
- if [ "$newsrc" != "$oldsrc" ]; then
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="DROP FUNCTION public.myfunc(integer);"
- ;;
- esac
- fix_sql="$fix_sql
- DROP FUNCTION IF EXISTS
- public.oldstyle_length(integer, text); -- last in 9.6
- DROP FUNCTION IF EXISTS
- public.putenv(text); -- last in v13
- DROP OPERATOR IF EXISTS -- last in v13
- public.#@# (pg_catalog.int8, NONE),
- public.#%# (pg_catalog.int8, NONE),
- public.!=- (pg_catalog.int8, NONE),
- public.#@%# (pg_catalog.int8, NONE);"
- psql -X -d regression -c "$fix_sql;" || psql_fix_sql_status=$?
- fi
-
- pg_dumpall --no-sync -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
-
- if [ "$newsrc" != "$oldsrc" ]; then
- # update references to old source tree's regress.so etc
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%';"
- ;;
- *)
- fix_sql="UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';"
- ;;
- esac
- psql -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA="$BASE_PGDATA"
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "$PGDATA" -b "$oldbindir" -p "$PGPORT" -P "$PGPORT"
-
-# make sure all directories and files have group permissions, on Unix hosts
-# Windows hosts don't support Unix-y permissions.
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type f ! -perm 640 | wc -l` -ne 0 ]; then
- echo "files in PGDATA with permission != 640";
- exit 1;
- fi ;;
-esac
-
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type d ! -perm 750 | wc -l` -ne 0 ]; then
- echo "directories in PGDATA with permission != 750";
- exit 1;
- fi ;;
-esac
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-pg_dumpall --no-sync -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) MSYS2_ARG_CONV_EXCL=/c cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm
index c59da758c7..1033f5f614 100644
--- a/src/test/perl/PostgresNode.pm
+++ b/src/test/perl/PostgresNode.pm
@@ -316,6 +316,31 @@ sub install_path
=pod
+=item $node->config_data($option)
+
+Grab some data from pg_config, with $option being the switch
+used.
+
+=cut
+
+sub config_data
+{
+ my ($self, $option) = @_;
+ local %ENV = $self->_get_env();
+
+ my ($stdout, $stderr);
+ my $result =
+ IPC::Run::run [ $self->installed_command('pg_config'), $option ],
+ '>', \$stdout, '2>', \$stderr
+ or die "could not execute pg_config";
+ chomp($stdout);
+ $stdout =~ s/\r$//;
+
+ return $stdout;
+}
+
+=pod
+
=item $node->info()
Return a string containing human-readable diagnostic information (paths, etc)
--
2.33.0
Attachments:
[text/plain] v3-0001-Switch-tests-of-pg_upgrade-to-use-TAP.patch (23.1K, ../../[email protected]/2-v3-0001-Switch-tests-of-pg_upgrade-to-use-TAP.patch)
download | inline diff:
From 6580f1b9bcf12a2b65e90f355ecf10250c121603 Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email protected]>
Date: Wed, 8 Sep 2021 15:30:57 +0900
Subject: [PATCH v3] Switch tests of pg_upgrade to use TAP
---
src/bin/pg_upgrade/Makefile | 17 +-
src/bin/pg_upgrade/TESTING | 29 ++-
src/bin/pg_upgrade/t/001_basic.pl | 9 +
src/bin/pg_upgrade/t/002_pg_upgrade.pl | 277 +++++++++++++++++++++++++
src/bin/pg_upgrade/test.sh | 272 ------------------------
src/test/perl/PostgresNode.pm | 25 +++
6 files changed, 334 insertions(+), 295 deletions(-)
create mode 100644 src/bin/pg_upgrade/t/001_basic.pl
create mode 100644 src/bin/pg_upgrade/t/002_pg_upgrade.pl
delete mode 100644 src/bin/pg_upgrade/test.sh
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 44d06be5a6..fa8dee0a9c 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -49,17 +49,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-# When $(MAKE) is present, make automatically infers that this is a
-# recursive make. which is not actually what we want here, as that
-# e.g. prevents output synchronization from working (as make thinks
-# that the subsidiary make knows how to deal with that itself, but
-# we're invoking a shell script that doesn't know). Referencing
-# $(MAKE) indirectly avoids that behaviour.
-# See https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable
-NOTSUBMAKEMAKE=$(MAKE)
+check:
+ $(prove_check)
-check: test.sh all temp-install
- MAKE=$(NOTSUBMAKEMAKE) $(with_temp_install) bindir=$(abs_top_builddir)/tmp_install/$(bindir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $<
-
-# installcheck is not supported because there's no meaningful way to test
-# pg_upgrade against a single already-running server
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
index e69874b42d..185943dd4b 100644
--- a/src/bin/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -4,19 +4,26 @@ 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.
+in this directory. 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.
-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:
+To test an upgrade from a different version, there are two options
+available:
+
+1) You have a built source tree for the old version as well as this
+version's binaries. Then set up the following variables:
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
+export oldinstall=...otherversion/bin (old version's install base path)
+
+2) You have a dump that can be used to set up the old version, as well
+as this version's binaries. Then set up the following variables:
+export olddump=...somewhere/dump.sql (old version's dump)
+export oldinstall=...otherversion/bin (old version's install base path)
+
+Finally, the tests can be done by running
+ make check
In this case, you will have to manually eyeball the resulting dump
diff for version-specific differences, as explained below.
@@ -87,3 +94,5 @@ steps:
7) Diff the regression database dump file with the regression dump
file loaded into the old server.
+
+The generated dump may be reusable with "olddump", as defined above.
diff --git a/src/bin/pg_upgrade/t/001_basic.pl b/src/bin/pg_upgrade/t/001_basic.pl
new file mode 100644
index 0000000000..605a7f622f
--- /dev/null
+++ b/src/bin/pg_upgrade/t/001_basic.pl
@@ -0,0 +1,9 @@
+use strict;
+use warnings;
+
+use TestLib;
+use Test::More tests => 8;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
new file mode 100644
index 0000000000..0bdbe6dc26
--- /dev/null
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -0,0 +1,277 @@
+# Set of tests for pg_upgrade.
+use strict;
+use warnings;
+
+use Cwd qw(abs_path getcwd);
+use File::Basename qw(dirname);
+
+use PostgresNode;
+use TestLib;
+use Test::More tests => 4;
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log([ 'createdb', '--port', $node->port, $dbname ]);
+}
+
+my $startdir = getcwd();
+
+# From now on, the test of pg_upgrade consists in setting up an instance.
+# This is the source instance used for the upgrade. Then a new and fresh
+# instance is created, and is used as the target instance for the
+# upgrade. Before running an upgrade a logical dump of the old instance
+# is taken, and a second logical dump of the new instance is taken after
+# the upgrade. The upgrade test passes if there are no differences after
+# running pg_upgrade.
+
+# Testing upgrades with an older instance of PostgreSQL requires
+# setting up two environment variables, among the following:
+# - "oldsrc", to point to the code source of the older version.
+# This is required to set up the old instance with pg_upgrade.
+# - "olddump", to point to a dump file that will be used to set
+# up the old instance to upgrade from.
+# - "oldinstall", to point to the installation path of the older
+# version.
+
+# "oldsrc" and "olddump" cannot be used together. Setting up
+# "olddump" and "oldinstall" will use the dump pointed to to
+# set up the old instance. If "oldsrc" is used instead of "olddump",
+# the full set of regression tests of the old instance is run
+# instead.
+
+if (defined($ENV{oldsrc}) && defined($ENV{olddump}))
+{
+ die "oldsrc and olddump are both defined";
+}
+elsif (defined($ENV{oldsrc}))
+{
+ if ( (defined($ENV{oldsrc}) && !defined($ENV{oldinstall}))
+ || (!defined($ENV{oldsrc}) && defined($ENV{oldinstall})))
+ {
+ # Not all variables are defined, so leave and die if test is
+ # done with an older installation.
+ die "oldsrc or oldinstall is undefined";
+ }
+}
+elsif (defined($ENV{olddump}))
+{
+ if ( (defined($ENV{olddump}) && !defined($ENV{oldinstall}))
+ || (!defined($ENV{olddump}) && defined($ENV{oldinstall})))
+ {
+ # Not all variables are defined, so leave and die if test is
+ # done with an older installation.
+ die "olddump or oldinstall is undefined";
+ }
+}
+
+if ((defined($ENV{oldsrc}) || defined($ENV{olddump})) && $windows_os)
+{
+ # This configuration is not supported on Windows, as regress.so
+ # location diverges across the compilation methods used on this
+ # platform.
+ die "No support for older version tests on Windows";
+}
+
+# Default is the location of this source code for both nodes used with
+# the upgrade.
+my $newsrc = abs_path("../../..");
+my $oldsrc = $ENV{oldsrc} || $newsrc;
+$oldsrc = abs_path($oldsrc);
+
+# Temporary location for the dumps taken
+my $tempdir = TestLib::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = PostgresNode->new('old_node', install_path => $ENV{oldinstall});
+
+$oldnode->init(extra => [ '--locale', 'C', '--encoding', 'LATIN1' ]);
+$oldnode->start;
+
+# Set up the data of the old instance with pg_regress or an old dump.
+if (defined($ENV{olddump}))
+{
+ # Use the dump specified.
+ my $olddumpfile = $ENV{olddump};
+ die "no dump file found!" unless -e $olddumpfile;
+
+ # Load the dump, and we are done here.
+ $oldnode->command_ok(
+ [ 'psql', '-f', $olddumpfile, '--port', $oldnode->port, 'postgres' ]);
+}
+else
+{
+ # Default is to just use pg_regress to setup the old instance
+ # Creating databases with names covering most ASCII bytes
+ generate_db($oldnode, 1, 45);
+ generate_db($oldnode, 46, 90);
+ generate_db($oldnode, 91, 127);
+
+ # Run core regression tests on the old instance.
+ $oldnode->run_log([ "createdb", '--port', $oldnode->port, 'regression' ]);
+
+ # This is more a trick than anything else, as pg_regress needs to be
+ # from the old instance. --dlpath is needed to be able to find the
+ # location of regress.so, and it is located in the same folder as
+ # pg_regress itself.
+
+ # Grab any regression options that may be passed down by caller.
+ my $extra_opts_val = $ENV{EXTRA_REGRESS_OPT} || "";
+ my @extra_opts = split(/\s+/, $extra_opts_val);
+
+ chdir "$oldsrc/src/test/regress/";
+ my @regress_command = [
+ $ENV{PG_REGRESS}, '--schedule',
+ 'parallel_schedule', '--bindir',
+ $oldnode->config_data('--bindir'), '--make-testtablespace-dir',
+ '--dlpath', '.',
+ '--use-existing', '--port',
+ $oldnode->port
+ ];
+ @regress_command = (@regress_command, @extra_opts);
+
+ $oldnode->command_ok(@regress_command,
+ 'regression test run on old instance');
+
+ # Move back to the start path.
+ chdir $startdir;
+}
+
+# Before dumping, get rid of objects not existing or not supported in later
+# versions. This depends on the version of the old server used, and matters
+# only if different versions are used for the dump.
+my ($result, $oldpgversion, $stderr) =
+ $oldnode->psql('postgres', qq[SHOW server_version_num;]);
+my $fix_sql;
+
+if (defined($ENV{oldinstall}))
+{
+ # Changes for PostgreSQL ~13
+ if ($oldpgversion < 140000)
+ {
+ # Postfix operators are not supported anymore in 14.
+ $oldnode->psql(
+ 'regression', "
+ DROP OPERATOR IF EXISTS #@# (bigint,NONE);
+ DROP OPERATOR IF EXISTS #%# (bigint,NONE);
+ DROP OPERATOR IF EXISTS !=- (bigint,NONE);
+ DROP OPERATOR IF EXISTS #@%# (bigint,NONE);");
+ # Last appeared in 13.
+ $oldnode->psql('regression', "DROP FUNCTION public.putenv(text);");
+ }
+
+ # Changes for PostgreSQL ~9.6
+ if ($oldpgversion < 100000)
+ {
+ # Last appeared in 9.6.
+ $oldnode->psql('regression',
+ "DROP FUNCTION public.oldstyle_length(integer, text);");
+ }
+
+ # Add here tweaks to objects to adapt to newer versions.
+}
+
+# Initialize a new node for the upgrade. This is done early so as it is
+# possible to know with which node's PATH the initial dump needs to be
+# taken.
+my $newnode = PostgresNode->new('new_node');
+$newnode->init(extra => [ '--locale=C', '--encoding=LATIN1' ]);
+my $newbindir = $newnode->config_data('--bindir');
+my $oldbindir = $oldnode->config_data('--bindir');
+
+# Take a dump before performing the upgrade as a base comparison. Note
+# that we need to use pg_dumpall from the new node here.
+$newnode->command_ok(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $oldnode->connstr('postgres'),
+ '-f', "$tempdir/dump1.sql"
+ ],
+ 'dump before running pg_upgrade');
+
+# After dumping, update references to the old source tree's regress.so
+# to point to the new tree.
+if (defined($ENV{oldinstall}))
+{
+ # First, fetch all the references to libraries that are not part
+ # of the default path $libdir.
+ my $output = $oldnode->safe_psql('regression',
+ "SELECT DISTINCT probin::text FROM pg_proc WHERE probin NOT LIKE '\$libdir%';"
+ );
+ chomp($output);
+ my @libpaths = split("\n", $output);
+
+ my $dump_data = slurp_file("$tempdir/dump1.sql");
+
+ my $newregresssrc = "$newsrc/src/test/regress";
+ foreach (@libpaths)
+ {
+ my $libpath = $_;
+ $libpath = dirname($libpath);
+ $dump_data =~ s/$libpath/$newregresssrc/g;
+ }
+
+ open my $fh, ">", "$tempdir/dump1.sql" or die "could not open dump file";
+ print $fh $dump_data;
+ close $fh;
+
+ # This replaces any references to the old tree's regress.so
+ # the new tree's regress.so. Any references that do *not*
+ # match $libdir are switched so as this request does not
+ # depend on the path of the old source tree. This is useful
+ # when using an old dump. Do the operation on all the database
+ # that allow connections so as this includes the regression
+ # database and anything the user has set up.
+ $output = $oldnode->safe_psql('postgres',
+ "SELECT datname FROM pg_database WHERE datallowconn;"
+ );
+ chomp($output);
+ my @datnames = split("\n", $output);
+ foreach (@datnames)
+ {
+ my $datname = $_;
+ $oldnode->safe_psql(
+ $datname, "UPDATE pg_proc SET probin =
+ regexp_replace(probin, '.*/', '$newregresssrc/')
+ WHERE probin NOT LIKE '\$libdir/%'");
+ }
+}
+
+# Move back to current directory, all logs generated need to be located
+# at the origin.
+chdir $startdir;
+
+# Update the instance.
+$oldnode->stop;
+
+# Time for the real run.
+chdir "$newsrc/src/test/regress";
+$newnode->command_ok(
+ [
+ 'pg_upgrade', '-d', $oldnode->data_dir, '-D',
+ $newnode->data_dir, '-b', $oldbindir, '-B',
+ $newbindir, '-p', $oldnode->port, '-P',
+ $newnode->port
+ ],
+ 'run of pg_upgrade for new instance');
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+$newnode->run_log(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $newnode->connstr('postgres'),
+ '-f', "$tempdir/dump2.sql"
+ ]);
+
+# Compare the two dumps, there should be no differences.
+command_ok([ 'diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql" ],
+ 'Old and new dump match after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index 1ba326decd..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,272 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2021, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- # To increase coverage of non-standard segment size and group access
- # without increasing test runtime, run these tests with a custom setting.
- # Also, specify "-A trust" explicitly to suppress initdb's warning.
- "$1" -N --wal-segsize 1 -g -A trust
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# What flavor of host are we on?
-# Treat MINGW* (msys1) and MSYS* (msys2) the same.
-testhost=`uname -s | sed 's/^MSYS/MINGW/'`
-
-# Establish how the server will listen for connections
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PG_REGRESS_SOCKET_DIR=""
- PGHOST=localhost
- ;;
- *)
- LISTEN_ADDRESSES=""
- # Select a socket directory. The algorithm is from the "configure"
- # script; the outcome mimics pg_regress.c:make_temp_sockdir().
- if [ x"$PG_REGRESS_SOCKET_DIR" = x ]; then
- set +e
- dir=`(umask 077 &&
- mktemp -d /tmp/pg_upgrade_check-XXXXXX) 2>/dev/null`
- if [ ! -d "$dir" ]; then
- dir=/tmp/pg_upgrade_check-$$-$RANDOM
- (umask 077 && mkdir "$dir")
- if [ ! -d "$dir" ]; then
- echo "could not create socket temporary directory in \"/tmp\""
- exit 1
- fi
- fi
- set -e
- PG_REGRESS_SOCKET_DIR=$dir
- trap 'rm -rf "$PG_REGRESS_SOCKET_DIR"' 0
- trap 'exit 3' 1 2 13 15
- fi
- PGHOST=$PG_REGRESS_SOCKET_DIR
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=\"$LISTEN_ADDRESSES\" -k \"$PG_REGRESS_SOCKET_DIR\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-temp_root=`pwd`/tmp_check
-rm -rf "$temp_root"
-mkdir "$temp_root"
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-# We need to make pg_regress use psql from the desired installation
-# (likely a temporary one), because otherwise the installcheck run
-# below would try to use psql from the proper installation directory
-# of the target version, which might be outdated or not exist. But
-# don't override anything else that's already in EXTRA_REGRESS_OPTS.
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$oldbindir'"
-export EXTRA_REGRESS_OPTS
-
-# While in normal cases this will already be set up, adding bindir to
-# path allows test.sh to be invoked with different versions as
-# described in ./TESTING
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA="$temp_root/data"
-PGDATA="${BASE_PGDATA}.old"
-export PGDATA
-
-# Send installcheck outputs to a private directory. This avoids conflict when
-# check-world runs pg_upgrade check concurrently with src/test/regress check.
-# To retrieve interesting files after a run, use pattern tmp_check/*/*.diffs.
-outputdir="$temp_root/regress"
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --outputdir=$outputdir"
-export EXTRA_REGRESS_OPTS
-mkdir "$outputdir"
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "regression$dbname1" || createdb_status=$?
-createdb "regression$dbname2" || createdb_status=$?
-createdb "regression$dbname3" || createdb_status=$?
-
-if "$MAKE" -C "$oldsrc" installcheck-parallel; then
- oldpgversion=`psql -X -A -t -d regression -c "SHOW server_version_num"`
-
- # before dumping, get rid of objects not feasible in later versions
- if [ "$newsrc" != "$oldsrc" ]; then
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="DROP FUNCTION public.myfunc(integer);"
- ;;
- esac
- fix_sql="$fix_sql
- DROP FUNCTION IF EXISTS
- public.oldstyle_length(integer, text); -- last in 9.6
- DROP FUNCTION IF EXISTS
- public.putenv(text); -- last in v13
- DROP OPERATOR IF EXISTS -- last in v13
- public.#@# (pg_catalog.int8, NONE),
- public.#%# (pg_catalog.int8, NONE),
- public.!=- (pg_catalog.int8, NONE),
- public.#@%# (pg_catalog.int8, NONE);"
- psql -X -d regression -c "$fix_sql;" || psql_fix_sql_status=$?
- fi
-
- pg_dumpall --no-sync -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
-
- if [ "$newsrc" != "$oldsrc" ]; then
- # update references to old source tree's regress.so etc
- fix_sql=""
- case $oldpgversion in
- 804??)
- fix_sql="UPDATE pg_proc SET probin = replace(probin::text, '$oldsrc', '$newsrc')::bytea WHERE probin LIKE '$oldsrc%';"
- ;;
- *)
- fix_sql="UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';"
- ;;
- esac
- psql -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA="$BASE_PGDATA"
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "$PGDATA" -b "$oldbindir" -p "$PGPORT" -P "$PGPORT"
-
-# make sure all directories and files have group permissions, on Unix hosts
-# Windows hosts don't support Unix-y permissions.
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type f ! -perm 640 | wc -l` -ne 0 ]; then
- echo "files in PGDATA with permission != 640";
- exit 1;
- fi ;;
-esac
-
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type d ! -perm 750 | wc -l` -ne 0 ]; then
- echo "directories in PGDATA with permission != 750";
- exit 1;
- fi ;;
-esac
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-pg_dumpall --no-sync -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) MSYS2_ARG_CONV_EXCL=/c cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm
index c59da758c7..1033f5f614 100644
--- a/src/test/perl/PostgresNode.pm
+++ b/src/test/perl/PostgresNode.pm
@@ -316,6 +316,31 @@ sub install_path
=pod
+=item $node->config_data($option)
+
+Grab some data from pg_config, with $option being the switch
+used.
+
+=cut
+
+sub config_data
+{
+ my ($self, $option) = @_;
+ local %ENV = $self->_get_env();
+
+ my ($stdout, $stderr);
+ my $result =
+ IPC::Run::run [ $self->installed_command('pg_config'), $option ],
+ '>', \$stdout, '2>', \$stderr
+ or die "could not execute pg_config";
+ chomp($stdout);
+ $stdout =~ s/\r$//;
+
+ return $stdout;
+}
+
+=pod
+
=item $node->info()
Return a string containing human-readable diagnostic information (paths, etc)
--
2.33.0
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2021-10-01 06:19 ` Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2021-10-01 06:19 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Postgres hackers <[email protected]>
On Thu, May 20, 2021 at 03:07:56PM +0900, Michael Paquier wrote:
> This stuff still needs to be expanded depending on how PostgresNode is
> made backward-compatible, but I'll wait for that to happen before
> going further down here. I have also spent some time testing all that
> with MSVC, and the installation paths used for pg_regress&co make the
> script a tad more confusing, so I have dropped this part for now.
Andrew, as this is a bit tied to the buildfarm code and any
simplifications that could happen there, do you have any comments
and/or suggestions for this patch?
This still applies on HEAD and it holds all the properties of the
existing test by using PostgresNodes that point to older installations
for the business with binaries and libraries business. There is one
part where pg_upgrade logs into src/test/regress/, which is not good,
but that should be easily fixable.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2021-10-02 20:58 ` Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andrew Dunstan @ 2021-10-02 20:58 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Postgres hackers <[email protected]>
On 10/1/21 2:19 AM, Michael Paquier wrote:
> On Thu, May 20, 2021 at 03:07:56PM +0900, Michael Paquier wrote:
>> This stuff still needs to be expanded depending on how PostgresNode is
>> made backward-compatible, but I'll wait for that to happen before
>> going further down here. I have also spent some time testing all that
>> with MSVC, and the installation paths used for pg_regress&co make the
>> script a tad more confusing, so I have dropped this part for now.
> Andrew, as this is a bit tied to the buildfarm code and any
> simplifications that could happen there, do you have any comments
> and/or suggestions for this patch?
I haven't looked at the patch closely yet, but from a buildfarm POV I
think the only thing that needs to be done is to inhibit the buildfarm
client module if the TAP tests are present. The buildfarm code that runs
TAP tests should automatically detect and run the new test.
I've just counted and there are 116 animals reporting check-pg_upgrade,
so we'd better put that out pronto. It's a little early but I'll try to
push out a release containing code for it on Monday or Tuesday (it's a
one line addition).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
@ 2021-10-02 21:03 ` Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Tom Lane @ 2021-10-02 21:03 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Postgres hackers <[email protected]>
Andrew Dunstan <[email protected]> writes:
> I haven't looked at the patch closely yet, but from a buildfarm POV I
> think the only thing that needs to be done is to inhibit the buildfarm
> client module if the TAP tests are present. The buildfarm code that runs
> TAP tests should automatically detect and run the new test.
> I've just counted and there are 116 animals reporting check-pg_upgrade,
> so we'd better put that out pronto. It's a little early but I'll try to
> push out a release containing code for it on Monday or Tuesday (it's a
> one line addition).
IIUC, the only problem for a non-updated animal would be that it'd
run the test twice? Or would it actually fail? If the latter,
we'd need to sit on the patch rather longer.
regards, tom lane
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
@ 2021-10-03 03:32 ` Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andrew Dunstan @ 2021-10-03 03:32 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Postgres hackers <[email protected]>
On 10/2/21 5:03 PM, Tom Lane wrote:
> Andrew Dunstan <[email protected]> writes:
>> I haven't looked at the patch closely yet, but from a buildfarm POV I
>> think the only thing that needs to be done is to inhibit the buildfarm
>> client module if the TAP tests are present. The buildfarm code that runs
>> TAP tests should automatically detect and run the new test.
>> I've just counted and there are 116 animals reporting check-pg_upgrade,
>> so we'd better put that out pronto. It's a little early but I'll try to
>> push out a release containing code for it on Monday or Tuesday (it's a
>> one line addition).
> IIUC, the only problem for a non-updated animal would be that it'd
> run the test twice? Or would it actually fail? If the latter,
> we'd need to sit on the patch rather longer.
>
>
The patch removes test.sh, so yes it would break.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
@ 2021-10-03 03:34 ` Tom Lane <[email protected]>
2021-10-03 07:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-03 12:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-12-14 02:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
0 siblings, 3 replies; 118+ messages in thread
From: Tom Lane @ 2021-10-03 03:34 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Michael Paquier <[email protected]>; Postgres hackers <[email protected]>
Andrew Dunstan <[email protected]> writes:
> On 10/2/21 5:03 PM, Tom Lane wrote:
>> IIUC, the only problem for a non-updated animal would be that it'd
>> run the test twice? Or would it actually fail? If the latter,
>> we'd need to sit on the patch rather longer.
> The patch removes test.sh, so yes it would break.
Maybe we could leave test.sh in place for awhile? I'd rather
not cause a flag day for buildfarm owners. (Also, how do we
see this working in the back branches?)
regards, tom lane
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
@ 2021-10-03 07:03 ` Michael Paquier <[email protected]>
2021-10-10 14:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Peter Eisentraut <[email protected]>
2 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2021-10-03 07:03 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote:
> Maybe we could leave test.sh in place for awhile? I'd rather
> not cause a flag day for buildfarm owners. (Also, how do we
> see this working in the back branches?)
I would be fine with test.sh staying around for now.
If we do that, though, I think that we had better remove the support
for upgrades across different major versions in test.sh, and keep this
capability in the new script. I am not sure that a lot of people use
that to begin with, but it would be weird to support that with a
different configuration layer for both at the same time (test.sh uses
a combination of bin/ and lib/ paths, while TAP uses just installation
path to accomodate with what PostgresNode.pm is able to do). The
patch of this thread also adds support for the load of an old dump
instead of an installcheck run of the old instance, which is something
the buildfarm could use.
I also looked two days ago at a proposal to move all the
pg_upgrade-specific SQLs into a new, separate, file that makes use of
psql's \if to do the job encoded now in test.sh. I think that it
would be strange to duplicate this logic in a the pg_upgrade TAP test
and test.sh if we finish by keeping both around for now. So that's a
second item we had better deal with first, in my opinion:
https://www.postgresql.org/message-id/YVa/[email protected]
Thoughts?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 07:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2021-10-10 14:07 ` Peter Eisentraut <[email protected]>
2021-10-11 00:40 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-11 13:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
0 siblings, 2 replies; 118+ messages in thread
From: Peter Eisentraut @ 2021-10-10 14:07 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Tom Lane <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On 03.10.21 09:03, Michael Paquier wrote:
> On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote:
>> Maybe we could leave test.sh in place for awhile? I'd rather
>> not cause a flag day for buildfarm owners. (Also, how do we
>> see this working in the back branches?)
>
> I would be fine with test.sh staying around for now.
test.sh could be changed to invoke the TAP test.
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 07:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-10 14:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Peter Eisentraut <[email protected]>
@ 2021-10-11 00:40 ` Michael Paquier <[email protected]>
1 sibling, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2021-10-11 00:40 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Sun, Oct 10, 2021 at 04:07:43PM +0200, Peter Eisentraut wrote:
> On 03.10.21 09:03, Michael Paquier wrote:
>> On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote:
>>> Maybe we could leave test.sh in place for awhile? I'd rather
>>> not cause a flag day for buildfarm owners. (Also, how do we
>>> see this working in the back branches?)
>>
>> I would be fine with test.sh staying around for now.
>
> test.sh could be changed to invoke the TAP test.
That would remove the possibility to run the tests of pg_upgrade with
--enable-tap-tests, which is the point I think Tom was making, because
TestUpgrade.pm in the buildfarm code just uses "make check" as of the
following:
$cmd = "cd $self->{pgsql}/src/bin/pg_upgrade && $make $instflags check";
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 07:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-10 14:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Peter Eisentraut <[email protected]>
@ 2021-10-11 13:04 ` Andrew Dunstan <[email protected]>
2021-10-12 04:48 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Andrew Dunstan @ 2021-10-11 13:04 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; Michael Paquier <[email protected]>; Tom Lane <[email protected]>; +Cc: Postgres hackers <[email protected]>
On 10/10/21 10:07 AM, Peter Eisentraut wrote:
> On 03.10.21 09:03, Michael Paquier wrote:
>> On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote:
>>> Maybe we could leave test.sh in place for awhile? I'd rather
>>> not cause a flag day for buildfarm owners. (Also, how do we
>>> see this working in the back branches?)
>>
>> I would be fine with test.sh staying around for now.
>
> test.sh could be changed to invoke the TAP test.
Keeping test.sh is not necessary - I mis-remembered what the test module
does.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 07:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-10 14:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Peter Eisentraut <[email protected]>
2021-10-11 13:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
@ 2021-10-12 04:48 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2021-10-12 04:48 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; Postgres hackers <[email protected]>
On Mon, Oct 11, 2021 at 09:04:47AM -0400, Andrew Dunstan wrote:
> Keeping test.sh is not necessary - I mis-remembered what the test module
> does.
So.. Are people fine to remove entirely test.sh at the end, requiring
the tests of pg_upgrade to have TAP installed? I'd rather raise the
bar here, as it would keep the code simpler in the tree in the long
term. Or am I misunderstanding something?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
@ 2021-10-03 12:22 ` Andrew Dunstan <[email protected]>
2021-10-12 04:45 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2 siblings, 1 reply; 118+ messages in thread
From: Andrew Dunstan @ 2021-10-03 12:22 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Postgres hackers <[email protected]>
On 10/2/21 11:34 PM, Tom Lane wrote:
> Andrew Dunstan <[email protected]> writes:
>> On 10/2/21 5:03 PM, Tom Lane wrote:
>>> IIUC, the only problem for a non-updated animal would be that it'd
>>> run the test twice? Or would it actually fail? If the latter,
>>> we'd need to sit on the patch rather longer.
>> The patch removes test.sh, so yes it would break.
> Maybe we could leave test.sh in place for awhile? I'd rather
> not cause a flag day for buildfarm owners. (Also, how do we
> see this working in the back branches?)
>
>
Actually, I was wrong. The module just does "make check" for non-MSVC.
For MSVC it calls vcregress.pl, which the patch doesn't touch (it
should, I think).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 12:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
@ 2021-10-12 04:45 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2021-10-12 04:45 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: Tom Lane <[email protected]>; Postgres hackers <[email protected]>
On Sun, Oct 03, 2021 at 08:22:57AM -0400, Andrew Dunstan wrote:
> Actually, I was wrong. The module just does "make check" for non-MSVC.
> For MSVC it calls vcregress.pl, which the patch doesn't touch (it
> should, I think).
Yes, it should. And I'd like to do things so as we replace all the
internals of upgradecheck() by a call to tap_check(). The patch does
not work yet properly with MSVC, and there were some problems in
getting the invocation of pg_regress right as far as I recall. That's
why I have left this part for now. I don't see why we could not do
the MSVC part as an independent step though, getting rid of test.sh is
appealing enough in itself.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../YWUS%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
@ 2021-12-14 02:08 ` Andres Freund <[email protected]>
2021-12-14 05:31 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2 siblings, 1 reply; 118+ messages in thread
From: Andres Freund @ 2021-12-14 02:08 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Michael Paquier <[email protected]>; Postgres hackers <[email protected]>
Hi,
On 2021-10-02 23:34:38 -0400, Tom Lane wrote:
> Andrew Dunstan <[email protected]> writes:
> > On 10/2/21 5:03 PM, Tom Lane wrote:
> >> IIUC, the only problem for a non-updated animal would be that it'd
> >> run the test twice? Or would it actually fail? If the latter,
> >> we'd need to sit on the patch rather longer.
>
> > The patch removes test.sh, so yes it would break.
>
> Maybe we could leave test.sh in place for awhile? I'd rather
> not cause a flag day for buildfarm owners. (Also, how do we
> see this working in the back branches?)
Seems like we might get away with making make -C contrib/pg_upgrade check and
vcregress.pl upgradecheck do nothing?
For the common case of not testing cross-version stuff, pg_upgrade's tests
would just be invoked via run_build.pl:run_bin_tests(). And TestUpgrade.pm
should be fine with a test doing nothing.
We'd not loose coverage with non-updated BF animals unless they have tap tests
disabled. Just the cross-version test would need timely work by buildfarm
operators - but I think Andrew could deal with that.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-12-14 02:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
@ 2021-12-14 05:31 ` Michael Paquier <[email protected]>
2021-12-14 06:14 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2021-12-14 05:31 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Mon, Dec 13, 2021 at 06:08:24PM -0800, Andres Freund wrote:
> Seems like we might get away with making make -C contrib/pg_upgrade check and
> vcregress.pl upgradecheck do nothing?
You mean #contrib/#src/bin/# here, right? I don't think that we have
any need to have "make -C" do nothing. For vcregress.pl, we should
IMO just remove upgradecheck.
> For the common case of not testing cross-version stuff, pg_upgrade's tests
> would just be invoked via run_build.pl:run_bin_tests(). And TestUpgrade.pm
> should be fine with a test doing nothing.
Perhaps. I am not sure what's the best picture here, TBH. One
difference between the core stuff and the buldfarm is that in the case
of the buildfarm, we upgrade from a version that has not only the main
regression database, but everything from the contrib/ modules.
Speaking of which, I am going to send a patch for the buildfarm to be
able to use the SQL file from 0df9641, so as committers gain a bit
more control on the cross-version upgrade tests run by the buildfarm,
using the in-core code a maximum.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-12-14 02:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2021-12-14 05:31 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2021-12-14 06:14 ` Andres Freund <[email protected]>
2021-12-15 01:47 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andres Freund @ 2021-12-14 06:14 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On 2021-12-14 14:31:24 +0900, Michael Paquier wrote:
> On Mon, Dec 13, 2021 at 06:08:24PM -0800, Andres Freund wrote:
> > Seems like we might get away with making make -C contrib/pg_upgrade check and
> > vcregress.pl upgradecheck do nothing?
>
> You mean #contrib/#src/bin/# here, right? I don't think that we have
> any need to have "make -C" do nothing. For vcregress.pl, we should
> IMO just remove upgradecheck.
Tom's point was that the buildfarm scripts do
if ($self->{bfconf}->{using_msvc})
@checklog = run_log("perl vcregress.pl upgradecheck");
else
"cd $self->{pgsql}/src/bin/pg_upgrade && $make $instflags check";
if we don't want to break every buildfarm member that has TestUpgrade enabled
the moment this is committed, we need to have a backward compat path.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-12-14 02:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2021-12-14 05:31 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-12-14 06:14 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
@ 2021-12-15 01:47 ` Michael Paquier <[email protected]>
2021-12-16 02:51 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2021-12-15 01:47 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Mon, Dec 13, 2021 at 10:14:49PM -0800, Andres Freund wrote:
> Tom's point was that the buildfarm scripts do
> if ($self->{bfconf}->{using_msvc})
> @checklog = run_log("perl vcregress.pl upgradecheck");
> else
> "cd $self->{pgsql}/src/bin/pg_upgrade && $make $instflags check";
>
> if we don't want to break every buildfarm member that has TestUpgrade enabled
> the moment this is committed, we need to have a backward compat path.
Missed that, thanks! I'll think about all that a bit more before
sending a long-overdue rebased version.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-12-14 02:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2021-12-14 05:31 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-12-14 06:14 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2021-12-15 01:47 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2021-12-16 02:51 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2021-12-16 02:51 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Wed, Dec 15, 2021 at 10:47:24AM +0900, Michael Paquier wrote:
> Missed that, thanks! I'll think about all that a bit more before
> sending a long-overdue rebased version.
Okay, here is finally a rebase of this patch, where I have fixed a
couple of existing issues, and I have extended the patch to the point
where the support range is what I expect should be. In short:
- Added support for MSVC for the TAP test. I have considered making
upgradecheck silent, but after thinking about it I have just filtered
pg_upgrade from bincheck, and simplified upgradecheck to launch the
new test. It is simple to switch from one approach to another. This
shaves some code in vcregress.pl.
- Fixed a set of issues with various chdir commands in the previous
patches. The command of pg_regress has been tweaked so as all results
are part of src/bin/pg_upgrade/. Any logs generated by pg_upgrade
stay in this location, same way as HEAD.
- Adapted to the new modules of src/test/perl/.
- Support for cross-upgrades now uses upgrade_adapt.sql (I have sent a
patch for the buildfarm client about that yesterday actually), same
way as test.sh on HEAD. Like HEAD, attempting to use the
cross-version HEAD causes diffs between the old and the new dumps.
But there is nothing new here. This could be improved more but the
attached does already a lot.
- Like the previous versions, this supports two modes when setting up
the to-be-upgraded cluster: setup things from an old dump or use
pg_regress. The buildfarm does the former for upgrades down to 9.2.
The core code does the latter.
I may have missed one thing or two, but I think that's pretty much
what we should be looking for to do the switch to TAP in terms of
coverage.
--
Michael
Attachments:
[text/x-diff] v4-0001-Switch-tests-of-pg_upgrade-to-use-TAP.patch (28.1K, ../../[email protected]/2-v4-0001-Switch-tests-of-pg_upgrade-to-use-TAP.patch)
download | inline diff:
From 47fcfac534f947595a880eacdbcfe4f8bd6af516 Mon Sep 17 00:00:00 2001
From: Michael Paquier <[email protected]>
Date: Thu, 16 Dec 2021 11:50:54 +0900
Subject: [PATCH v4] Switch tests of pg_upgrade to use TAP
---
src/bin/pg_upgrade/.gitignore | 5 +
src/bin/pg_upgrade/Makefile | 23 +-
src/bin/pg_upgrade/TESTING | 33 ++-
src/bin/pg_upgrade/t/001_basic.pl | 9 +
src/bin/pg_upgrade/t/002_pg_upgrade.pl | 275 ++++++++++++++++++++++
src/bin/pg_upgrade/test.sh | 279 -----------------------
src/test/perl/PostgreSQL/Test/Cluster.pm | 25 ++
src/tools/msvc/vcregress.pl | 91 +-------
8 files changed, 355 insertions(+), 385 deletions(-)
create mode 100644 src/bin/pg_upgrade/t/001_basic.pl
create mode 100644 src/bin/pg_upgrade/t/002_pg_upgrade.pl
delete mode 100644 src/bin/pg_upgrade/test.sh
diff --git a/src/bin/pg_upgrade/.gitignore b/src/bin/pg_upgrade/.gitignore
index 2d3bfeaa50..3b64522ab6 100644
--- a/src/bin/pg_upgrade/.gitignore
+++ b/src/bin/pg_upgrade/.gitignore
@@ -7,3 +7,8 @@
/loadable_libraries.txt
/log/
/tmp_check/
+
+# Generated by pg_regress
+/sql/
+/expected/
+/results/
diff --git a/src/bin/pg_upgrade/Makefile b/src/bin/pg_upgrade/Makefile
index 44d06be5a6..35b6c123a5 100644
--- a/src/bin/pg_upgrade/Makefile
+++ b/src/bin/pg_upgrade/Makefile
@@ -28,6 +28,12 @@ OBJS = \
override CPPFLAGS := -DDLSUFFIX=\"$(DLSUFFIX)\" -I$(srcdir) -I$(libpq_srcdir) $(CPPFLAGS)
LDFLAGS_INTERNAL += -L$(top_builddir)/src/fe_utils -lpgfeutils $(libpq_pgport)
+# required for 002_pg_upgrade.pl
+REGRESS_SHLIB=$(abs_top_builddir)/src/test/regress/regress$(DLSUFFIX)
+export REGRESS_SHLIB
+REGRESS_OUTPUTDIR=$(abs_top_builddir)/src/bin/pg_upgrade
+export REGRESS_OUTPUTDIR
+
all: pg_upgrade
pg_upgrade: $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
@@ -49,17 +55,8 @@ clean distclean maintainer-clean:
pg_upgrade_dump_globals.sql \
pg_upgrade_dump_*.custom pg_upgrade_*.log
-# When $(MAKE) is present, make automatically infers that this is a
-# recursive make. which is not actually what we want here, as that
-# e.g. prevents output synchronization from working (as make thinks
-# that the subsidiary make knows how to deal with that itself, but
-# we're invoking a shell script that doesn't know). Referencing
-# $(MAKE) indirectly avoids that behaviour.
-# See https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable
-NOTSUBMAKEMAKE=$(MAKE)
+check:
+ $(prove_check)
-check: test.sh all temp-install
- MAKE=$(NOTSUBMAKEMAKE) $(with_temp_install) bindir=$(abs_top_builddir)/tmp_install/$(bindir) EXTRA_REGRESS_OPTS="$(EXTRA_REGRESS_OPTS)" $(SHELL) $<
-
-# installcheck is not supported because there's no meaningful way to test
-# pg_upgrade against a single already-running server
+installcheck:
+ $(prove_installcheck)
diff --git a/src/bin/pg_upgrade/TESTING b/src/bin/pg_upgrade/TESTING
index e69874b42d..acf769386a 100644
--- a/src/bin/pg_upgrade/TESTING
+++ b/src/bin/pg_upgrade/TESTING
@@ -2,21 +2,30 @@ THE SHORT VERSION
-----------------
On non-Windows machines, you can execute the testing process
-described below by running
+described below by running the following command in this directory:
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:
+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.
+
+To test an upgrade from a different version, there are two options
+available:
+
+1) You have a built source tree for the old version as well as this
+version's binaries. Then set up the following variables before
+launching the test:
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
+export oldinstall=...otherversion/ (old version's install base path)
+
+2) You have a dump that can be used to set up the old version, as well
+as this version's binaries. Then set up the following variables:
+export olddump=...somewhere/dump.sql (old version's dump)
+export oldinstall=...otherversion/ (old version's install base path)
+
+Finally, the tests can be done by running
+ make check
In this case, you will have to manually eyeball the resulting dump
diff for version-specific differences, as explained below.
@@ -87,3 +96,5 @@ steps:
7) Diff the regression database dump file with the regression dump
file loaded into the old server.
+
+The generated dump may be reusable with "olddump", as defined above.
diff --git a/src/bin/pg_upgrade/t/001_basic.pl b/src/bin/pg_upgrade/t/001_basic.pl
new file mode 100644
index 0000000000..75b0f98b08
--- /dev/null
+++ b/src/bin/pg_upgrade/t/001_basic.pl
@@ -0,0 +1,9 @@
+use strict;
+use warnings;
+
+use PostgreSQL::Test::Utils;
+use Test::More tests => 8;
+
+program_help_ok('pg_upgrade');
+program_version_ok('pg_upgrade');
+program_options_handling_ok('pg_upgrade');
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
new file mode 100644
index 0000000000..721741d0f8
--- /dev/null
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -0,0 +1,275 @@
+# Set of tests for pg_upgrade, including cross-version checks.
+use strict;
+use warnings;
+
+use Cwd qw(abs_path getcwd);
+use File::Basename qw(dirname);
+
+use PostgreSQL::Test::Cluster;
+use PostgreSQL::Test::Utils;
+use Test::More tests => 4;
+
+# Generate a database with a name made of a range of ASCII characters.
+sub generate_db
+{
+ my ($node, $from_char, $to_char) = @_;
+
+ my $dbname = '';
+ for my $i ($from_char .. $to_char)
+ {
+ next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
+ $dbname = $dbname . sprintf('%c', $i);
+ }
+ $node->run_log([ 'createdb', '--port', $node->port, $dbname ]);
+}
+
+# From now on, the test of pg_upgrade consists in setting up an instance.
+# This is the source instance used for the upgrade. Then a new and fresh
+# instance is created, and is used as the target instance for the
+# upgrade. Before running an upgrade a logical dump of the old instance
+# is taken, and a second logical dump of the new instance is taken after
+# the upgrade. The upgrade test passes if there are no differences after
+# running pg_upgrade.
+
+# Testing upgrades with an older instance of PostgreSQL requires
+# setting up two environment variables, among the following:
+# - "oldsrc", to point to the code source of the older version.
+# This is required to set up the old instance with pg_upgrade.
+# - "olddump", to point to a dump file that will be used to set
+# up the old instance to upgrade from.
+# - "oldinstall", to point to the installation path of the older
+# version.
+
+# "oldsrc" and "olddump" cannot be used together. Setting up
+# "olddump" and "oldinstall" will use the dump pointed to to
+# set up the old instance. If "oldsrc" is used instead of "olddump",
+# the full set of regression tests of the old instance is run
+# instead.
+
+if (defined($ENV{oldsrc}) && defined($ENV{olddump}))
+{
+ die "oldsrc and olddump are both defined";
+}
+elsif (defined($ENV{oldsrc}))
+{
+ if ( (defined($ENV{oldsrc}) && !defined($ENV{oldinstall}))
+ || (!defined($ENV{oldsrc}) && defined($ENV{oldinstall})))
+ {
+ # Not all variables are defined, so leave and die if test is
+ # done with an older installation.
+ die "oldsrc or oldinstall is undefined";
+ }
+}
+elsif (defined($ENV{olddump}))
+{
+ if ( (defined($ENV{olddump}) && !defined($ENV{oldinstall}))
+ || (!defined($ENV{olddump}) && defined($ENV{oldinstall})))
+ {
+ # Not all variables are defined, so leave and die if test is
+ # done with an older installation.
+ die "olddump or oldinstall is undefined";
+ }
+}
+
+if ((defined($ENV{oldsrc}) || defined($ENV{olddump})) && $windows_os)
+{
+ # This configuration is not supported on Windows, as regress.so
+ # location diverges across the compilation methods used on this
+ # platform.
+ die "No support for older version tests on Windows";
+}
+
+# Default is the location of this source code for both nodes used with
+# the upgrade.
+my $newsrc = abs_path("../../..");
+my $oldsrc = $ENV{oldsrc} || $newsrc;
+$oldsrc = abs_path($oldsrc);
+
+# Temporary location for the dumps taken
+my $tempdir = PostgreSQL::Test::Utils::tempdir;
+
+# Initialize node to upgrade
+my $oldnode = PostgreSQL::Test::Cluster->new('old_node',
+ install_path => $ENV{oldinstall});
+
+$oldnode->init(extra => [ '--locale', 'C', '--encoding', 'LATIN1' ]);
+$oldnode->start;
+
+# Set up the data of the old instance with pg_regress or an old dump.
+if (defined($ENV{olddump}))
+{
+ # Use the dump specified.
+ my $olddumpfile = $ENV{olddump};
+ die "no dump file found!" unless -e $olddumpfile;
+
+ # Load the dump, and we are done here.
+ $oldnode->command_ok(
+ [
+ 'psql', '-X', '-f', $olddumpfile,
+ '--port', $oldnode->port, 'regression'
+ ]);
+}
+else
+{
+ # Default is to just use pg_regress to setup the old instance
+ # Creating databases with names covering most ASCII bytes
+ generate_db($oldnode, 1, 45);
+ generate_db($oldnode, 46, 90);
+ generate_db($oldnode, 91, 127);
+
+ # Run core regression tests on the old instance.
+ $oldnode->run_log([ "createdb", '--port', $oldnode->port, 'regression' ]);
+
+ # Grab any regression options that may be passed down by caller.
+ my $extra_opts_val = $ENV{EXTRA_REGRESS_OPT} || "";
+ my @extra_opts = split(/\s+/, $extra_opts_val);
+
+ # --dlpath is needed to be able to find the location of regress.so and
+ # any libraries the regression tests required. This needs to point to
+ # in the old instance when using it. In the default case, fallback to
+ # what the caller provided for REGRESS_SHLIB.
+ my $dlpath;
+ if (defined($ENV{oldinstall}))
+ {
+ $dlpath = "$oldsrc/src/test/regress";
+ }
+ else
+ {
+ $dlpath = dirname($ENV{REGRESS_SHLIB});
+ }
+ $dlpath = PostgreSQL::Test::Utils::perl2host($dlpath);
+
+ # --outputdir points to the path where to place the output files, which
+ # had better be this directory.
+ my $outputdir =
+ PostgreSQL::Test::Utils::perl2host($ENV{REGRESS_OUTPUTDIR});
+
+ # --inputdir needs to point to the location of the input files, from the
+ # cluster to-be-upgraded.
+ my $inputdir =
+ PostgreSQL::Test::Utils::perl2host("$oldsrc/src/test/regress");
+
+ my @regress_command = [
+ $ENV{PG_REGRESS}, '--make-testtablespace-dir',
+ '--schedule', "$oldsrc/src/test/regress/parallel_schedule",
+ '--bindir', $oldnode->config_data('--bindir'),
+ '--dlpath', $dlpath,
+ '--port', $oldnode->port,
+ '--outputdir', $outputdir,
+ '--inputdir', $inputdir,
+ '--use-existing'
+ ];
+ @regress_command = (@regress_command, @extra_opts);
+
+ $oldnode->command_ok(@regress_command,
+ 'regression test run on old instance');
+}
+
+# Before dumping, get rid of objects not existing or not supported in later
+# versions. This depends on the version of the old server used, and matters
+# only if different versions are used for the dump.
+if (defined($ENV{oldinstall}))
+{
+ # Note that upgrade_adapt.sql from the new version is used, to
+ # cope with an upgrade to this version.
+ $oldnode->run_log(
+ [
+ 'psql', '-X', '-f',
+ PostgreSQL::Test::Utils::perl2host(
+ "$newsrc/src/bin/pg_upgrade/upgrade_adapt.sql"),
+ '--port',
+ $oldnode->port,
+ 'regression'
+ ]);
+}
+
+# Initialize a new node for the upgrade. This is done early so as it is
+# possible to know with which node's PATH the initial dump needs to be
+# taken.
+my $newnode = PostgreSQL::Test::Cluster->new('new_node');
+$newnode->init(extra => [ '--locale=C', '--encoding=LATIN1' ]);
+my $newbindir = $newnode->config_data('--bindir');
+my $oldbindir = $oldnode->config_data('--bindir');
+
+# Take a dump before performing the upgrade as a base comparison. Note
+# that we need to use pg_dumpall from the new node here.
+$newnode->command_ok(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $oldnode->connstr('postgres'),
+ '-f', "$tempdir/dump1.sql"
+ ],
+ 'dump before running pg_upgrade');
+
+# After dumping, update references to the old source tree's regress.so
+# to point to the new tree.
+if (defined($ENV{oldinstall}))
+{
+ # First, fetch all the references to libraries that are not part
+ # of the default path $libdir.
+ my $output = $oldnode->safe_psql('regression',
+ "SELECT DISTINCT probin::text FROM pg_proc WHERE probin NOT LIKE '\$libdir%';"
+ );
+ chomp($output);
+ my @libpaths = split("\n", $output);
+
+ my $dump_data = slurp_file("$tempdir/dump1.sql");
+
+ my $newregresssrc = "$newsrc/src/test/regress";
+ foreach (@libpaths)
+ {
+ my $libpath = $_;
+ $libpath = dirname($libpath);
+ $dump_data =~ s/$libpath/$newregresssrc/g;
+ }
+
+ open my $fh, ">", "$tempdir/dump1.sql" or die "could not open dump file";
+ print $fh $dump_data;
+ close $fh;
+
+ # This replaces any references to the old tree's regress.so
+ # the new tree's regress.so. Any references that do *not*
+ # match $libdir are switched so as this request does not
+ # depend on the path of the old source tree. This is useful
+ # when using an old dump. Do the operation on all the database
+ # that allow connections so as this includes the regression
+ # database and anything the user has set up.
+ $output = $oldnode->safe_psql('postgres',
+ "SELECT datname FROM pg_database WHERE datallowconn;");
+ chomp($output);
+ my @datnames = split("\n", $output);
+ foreach (@datnames)
+ {
+ my $datname = $_;
+ $oldnode->safe_psql(
+ $datname, "UPDATE pg_proc SET probin =
+ regexp_replace(probin, '.*/', '$newregresssrc/')
+ WHERE probin NOT LIKE '\$libdir/%'");
+ }
+}
+
+# Update the instance.
+$oldnode->stop;
+
+# Time for the real run.
+$newnode->command_ok(
+ [
+ 'pg_upgrade', '-d', $oldnode->data_dir, '-D',
+ $newnode->data_dir, '-b', $oldbindir, '-B',
+ $newbindir, '-p', $oldnode->port, '-P',
+ $newnode->port
+ ],
+ 'run of pg_upgrade for new instance');
+$newnode->start;
+
+# Take a second dump on the upgraded instance.
+$newnode->run_log(
+ [
+ 'pg_dumpall', '--no-sync',
+ '-d', $newnode->connstr('postgres'),
+ '-f', "$tempdir/dump2.sql"
+ ]);
+
+# Compare the two dumps, there should be no differences.
+command_ok([ 'diff', '-q', "$tempdir/dump1.sql", "$tempdir/dump2.sql" ],
+ 'old and new dump match after pg_upgrade');
diff --git a/src/bin/pg_upgrade/test.sh b/src/bin/pg_upgrade/test.sh
deleted file mode 100644
index 32d186d897..0000000000
--- a/src/bin/pg_upgrade/test.sh
+++ /dev/null
@@ -1,279 +0,0 @@
-#!/bin/sh
-
-# src/bin/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.
-#
-# Portions Copyright (c) 1996-2021, PostgreSQL Global Development Group
-# Portions Copyright (c) 1994, Regents of the University of California
-
-set -e
-
-: ${MAKE=make}
-
-# Guard against parallel make issues (see comments in pg_regress.c)
-unset MAKEFLAGS
-unset MAKELEVEL
-
-# Run a given "initdb" binary and overlay the regression testing
-# authentication configuration.
-standard_initdb() {
- # To increase coverage of non-standard segment size and group access
- # without increasing test runtime, run these tests with a custom setting.
- # Also, specify "-A trust" explicitly to suppress initdb's warning.
- # --allow-group-access and --wal-segsize have been added in v11.
- "$1" -N --wal-segsize 1 --allow-group-access -A trust
- if [ -n "$TEMP_CONFIG" -a -r "$TEMP_CONFIG" ]
- then
- cat "$TEMP_CONFIG" >> "$PGDATA/postgresql.conf"
- fi
- ../../test/regress/pg_regress --config-auth "$PGDATA"
-}
-
-# What flavor of host are we on?
-# Treat MINGW* (msys1) and MSYS* (msys2) the same.
-testhost=`uname -s | sed 's/^MSYS/MINGW/'`
-
-# Establish how the server will listen for connections
-case $testhost in
- MINGW*)
- LISTEN_ADDRESSES="localhost"
- PG_REGRESS_SOCKET_DIR=""
- PGHOST=localhost
- ;;
- *)
- LISTEN_ADDRESSES=""
- # Select a socket directory. The algorithm is from the "configure"
- # script; the outcome mimics pg_regress.c:make_temp_sockdir().
- if [ x"$PG_REGRESS_SOCKET_DIR" = x ]; then
- set +e
- dir=`(umask 077 &&
- mktemp -d /tmp/pg_upgrade_check-XXXXXX) 2>/dev/null`
- if [ ! -d "$dir" ]; then
- dir=/tmp/pg_upgrade_check-$$-$RANDOM
- (umask 077 && mkdir "$dir")
- if [ ! -d "$dir" ]; then
- echo "could not create socket temporary directory in \"/tmp\""
- exit 1
- fi
- fi
- set -e
- PG_REGRESS_SOCKET_DIR=$dir
- trap 'rm -rf "$PG_REGRESS_SOCKET_DIR"' 0
- trap 'exit 3' 1 2 13 15
- fi
- PGHOST=$PG_REGRESS_SOCKET_DIR
- ;;
-esac
-
-POSTMASTER_OPTS="-F -c listen_addresses=\"$LISTEN_ADDRESSES\" -k \"$PG_REGRESS_SOCKET_DIR\""
-export PGHOST
-
-# don't rely on $PWD here, as old shells don't set it
-temp_root=`pwd`/tmp_check
-rm -rf "$temp_root"
-mkdir "$temp_root"
-
-: ${oldbindir=$bindir}
-
-: ${oldsrc=../../..}
-oldsrc=`cd "$oldsrc" && pwd`
-newsrc=`cd ../../.. && pwd`
-
-# We need to make pg_regress use psql from the desired installation
-# (likely a temporary one), because otherwise the installcheck run
-# below would try to use psql from the proper installation directory
-# of the target version, which might be outdated or not exist. But
-# don't override anything else that's already in EXTRA_REGRESS_OPTS.
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --bindir='$oldbindir'"
-export EXTRA_REGRESS_OPTS
-
-# While in normal cases this will already be set up, adding bindir to
-# path allows test.sh to be invoked with different versions as
-# described in ./TESTING
-PATH=$bindir:$PATH
-export PATH
-
-BASE_PGDATA="$temp_root/data"
-PGDATA="${BASE_PGDATA}.old"
-export PGDATA
-
-# Send installcheck outputs to a private directory. This avoids conflict when
-# check-world runs pg_upgrade check concurrently with src/test/regress check.
-# To retrieve interesting files after a run, use pattern tmp_check/*/*.diffs.
-outputdir="$temp_root/regress"
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --outputdir=$outputdir"
-export EXTRA_REGRESS_OPTS
-mkdir "$outputdir"
-
-# pg_regress --make-tablespacedir would take care of that in 14~, but this is
-# still required for older versions where this option is not supported.
-if [ "$newsrc" != "$oldsrc" ]; then
- mkdir "$outputdir"/testtablespace
- mkdir "$outputdir"/sql
- mkdir "$outputdir"/expected
-fi
-
-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)
-#
-# 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
-PGSSLMODE=""; unset PGSSLMODE
-PGREQUIRESSL=""; unset PGREQUIRESSL
-PGCONNECT_TIMEOUT=""; unset PGCONNECT_TIMEOUT
-PGHOSTADDR=""; unset PGHOSTADDR
-
-# Select a non-conflicting port number, similarly to pg_regress.c
-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
-
-# buildfarm may try to override port via EXTRA_REGRESS_OPTS ...
-EXTRA_REGRESS_OPTS="$EXTRA_REGRESS_OPTS --port=$PGPORT"
-export EXTRA_REGRESS_OPTS
-
-standard_initdb "$oldbindir"/initdb
-"$oldbindir"/pg_ctl start -l "$logdir/postmaster1.log" -o "$POSTMASTER_OPTS" -w
-
-# Create databases with names covering the ASCII bytes other than NUL, BEL,
-# LF, or CR. BEL would ring the terminal bell in the course of this test, and
-# it is not otherwise a special case. PostgreSQL doesn't support the rest.
-dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
- if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
-# Exercise backslashes adjacent to double quotes, a Windows special case.
-dbname1='\"\'$dbname1'\\"\\\'
-dbname2=`awk 'BEGIN { for (i = 46; i < 91; i++) printf "%c", i }' </dev/null`
-dbname3=`awk 'BEGIN { for (i = 91; i < 128; i++) printf "%c", i }' </dev/null`
-createdb "regression$dbname1" || createdb_status=$?
-createdb "regression$dbname2" || createdb_status=$?
-createdb "regression$dbname3" || createdb_status=$?
-
-# Extra options to apply to the dump. This may be changed later.
-extra_dump_options=""
-
-if "$MAKE" -C "$oldsrc" installcheck-parallel; then
- oldpgversion=`psql -X -A -t -d regression -c "SHOW server_version_num"`
-
- # Before dumping, tweak the database of the old instance depending
- # on its version.
- if [ "$newsrc" != "$oldsrc" ]; then
- # This SQL script has its own idea of the cleanup that needs to be
- # done on the cluster to-be-upgraded, and includes version checks.
- # Note that this uses the script stored on the new branch.
- psql -X -d regression -f "$newsrc/src/bin/pg_upgrade/upgrade_adapt.sql" \
- || psql_fix_sql_status=$?
-
- # Handling of --extra-float-digits gets messy after v12.
- # Note that this changes the dumps from the old and new
- # instances if involving an old cluster of v11 or older.
- if [ $oldpgversion -lt 120000 ]; then
- extra_dump_options="--extra-float-digits=0"
- fi
- fi
-
- pg_dumpall $extra_dump_options --no-sync \
- -f "$temp_root"/dump1.sql || pg_dumpall1_status=$?
-
- if [ "$newsrc" != "$oldsrc" ]; then
- # update references to old source tree's regress.so etc
- fix_sql=""
- case $oldpgversion in
- *)
- fix_sql="UPDATE pg_proc SET probin = replace(probin, '$oldsrc', '$newsrc') WHERE probin LIKE '$oldsrc%';"
- ;;
- esac
- psql -X -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 "$createdb_status" ]; then
- exit 1
-fi
-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
-
-PGDATA="$BASE_PGDATA"
-
-standard_initdb 'initdb'
-
-pg_upgrade $PG_UPGRADE_OPTS -d "${PGDATA}.old" -D "$PGDATA" -b "$oldbindir" -p "$PGPORT" -P "$PGPORT"
-
-# make sure all directories and files have group permissions, on Unix hosts
-# Windows hosts don't support Unix-y permissions.
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type f ! -perm 640 | wc -l` -ne 0 ]; then
- echo "files in PGDATA with permission != 640";
- exit 1;
- fi ;;
-esac
-
-case $testhost in
- MINGW*|CYGWIN*) ;;
- *) if [ `find "$PGDATA" -type d ! -perm 750 | wc -l` -ne 0 ]; then
- echo "directories in PGDATA with permission != 750";
- exit 1;
- fi ;;
-esac
-
-pg_ctl start -l "$logdir/postmaster2.log" -o "$POSTMASTER_OPTS" -w
-
-pg_dumpall $extra_dump_options --no-sync \
- -f "$temp_root"/dump2.sql || pg_dumpall2_status=$?
-pg_ctl -m fast stop
-
-if [ -n "$pg_dumpall2_status" ]; then
- echo "pg_dumpall of post-upgrade database cluster failed"
- exit 1
-fi
-
-case $testhost in
- MINGW*) MSYS2_ARG_CONV_EXCL=/c cmd /c delete_old_cluster.bat ;;
- *) sh ./delete_old_cluster.sh ;;
-esac
-
-if diff "$temp_root"/dump1.sql "$temp_root"/dump2.sql >/dev/null; then
- echo PASSED
- exit 0
-else
- echo "Files $temp_root/dump1.sql and $temp_root/dump2.sql differ"
- echo "dumps were not identical"
- exit 1
-fi
diff --git a/src/test/perl/PostgreSQL/Test/Cluster.pm b/src/test/perl/PostgreSQL/Test/Cluster.pm
index c061e850fb..2bf2fcb69d 100644
--- a/src/test/perl/PostgreSQL/Test/Cluster.pm
+++ b/src/test/perl/PostgreSQL/Test/Cluster.pm
@@ -327,6 +327,31 @@ sub install_path
=pod
+=item $node->config_data($option)
+
+Grab some data from pg_config, with $option being the switched
+used.
+
+=cut
+
+sub config_data
+{
+ my ($self, $option) = @_;
+ local %ENV = $self->_get_env();
+
+ my ($stdout, $stderr);
+ my $result =
+ IPC::Run::run [ $self->installed_command('pg_config'), $option ],
+ '>', \$stdout, '2>', \$stderr
+ or die "could not execute pg_config";
+ chomp($stdout);
+ $stdout =~ s/\r$//;
+
+ return $stdout;
+}
+
+=pod
+
=item $node->info()
Return a string containing human-readable diagnostic information (paths, etc)
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index dc5b2df7d7..d62a15883e 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -287,6 +287,10 @@ sub bincheck
foreach my $dir (@bin_dirs)
{
next unless -d "$dir/t";
+ # Do not consider pg_upgrade, as it is handled by
+ # upgradecheck.
+ next if ($dir =~ "/pg_upgrade/");
+
my $status = tap_check($dir);
$mstat ||= $status;
}
@@ -591,89 +595,12 @@ sub generate_db
sub upgradecheck
{
- my $status;
- my $cwd = getcwd();
+ InstallTemp();
+ # Tweak environment for the upgrade tests
+ $ENV{REGRESS_OUTPUTDIR} = "$topdir/src/bin/pg_upgrade";
- # Much of this comes from the pg_upgrade test.sh script,
- # but it only covers the --install case, and not the case
- # where the old and new source or bin dirs are different.
- # i.e. only this version to this version check. That's
- # what pg_upgrade's "make check" does.
-
- $ENV{PGHOST} = 'localhost';
- $ENV{PGPORT} ||= 50432;
- my $tmp_root = "$topdir/src/bin/pg_upgrade/tmp_check";
- rmtree($tmp_root);
- mkdir $tmp_root || die $!;
- my $upg_tmp_install = "$tmp_root/install"; # unshared temp install
- print "Setting up temp install\n\n";
- Install($upg_tmp_install, "all", $config);
-
- # Install does a chdir, so change back after that
- chdir $cwd;
- my ($bindir, $libdir, $oldsrc, $newsrc) =
- ("$upg_tmp_install/bin", "$upg_tmp_install/lib", $topdir, $topdir);
- $ENV{PATH} = "$bindir;$ENV{PATH}";
- my $data = "$tmp_root/data";
- $ENV{PGDATA} = "$data.old";
- my $outputdir = "$tmp_root/regress";
- my @EXTRA_REGRESS_OPTS = ("--outputdir=$outputdir");
- mkdir "$outputdir" || die $!;
-
- my $logdir = "$topdir/src/bin/pg_upgrade/log";
- rmtree($logdir);
- mkdir $logdir || die $!;
- print "\nRunning initdb on old cluster\n\n";
- standard_initdb() or exit 1;
- print "\nStarting old cluster\n\n";
- my @args = ('pg_ctl', 'start', '-l', "$logdir/postmaster1.log");
- system(@args) == 0 or exit 1;
-
- print "\nCreating databases with names covering most ASCII bytes\n\n";
- generate_db("\\\"\\", 1, 45, "\\\\\"\\\\\\");
- generate_db('', 46, 90, '');
- generate_db('', 91, 127, '');
-
- print "\nSetting up data for upgrading\n\n";
- installcheck_internal('parallel', @EXTRA_REGRESS_OPTS);
-
- # now we can chdir into the source dir
- chdir "$topdir/src/bin/pg_upgrade";
- print "\nDumping old cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump1.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping old cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- $ENV{PGDATA} = "$data";
- print "\nSetting up new cluster\n\n";
- standard_initdb() or exit 1;
- print "\nRunning pg_upgrade\n\n";
- @args = ('pg_upgrade', '-d', "$data.old", '-D', $data, '-b', $bindir);
- system(@args) == 0 or exit 1;
- print "\nStarting new cluster\n\n";
- @args = ('pg_ctl', '-l', "$logdir/postmaster2.log", 'start');
- system(@args) == 0 or exit 1;
- print "\nDumping new cluster\n\n";
- @args = ('pg_dumpall', '-f', "$tmp_root/dump2.sql");
- system(@args) == 0 or exit 1;
- print "\nStopping new cluster\n\n";
- system("pg_ctl stop") == 0 or exit 1;
- print "\nDeleting old cluster\n\n";
- system(".\\delete_old_cluster.bat") == 0 or exit 1;
- print "\nComparing old and new cluster dumps\n\n";
-
- @args = ('diff', '-q', "$tmp_root/dump1.sql", "$tmp_root/dump2.sql");
- system(@args);
- $status = $?;
- if (!$status)
- {
- print "PASSED\n";
- }
- else
- {
- print "dumps not identical!\n";
- exit(1);
- }
+ my $mstat = tap_check("$topdir/src/bin/pg_upgrade");
+ exit $mstat if $mstat;
return;
}
--
2.34.1
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
@ 2022-03-31 04:10 Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-03-31 04:10 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Julien Rouhaud <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Thu, Mar 03, 2022 at 02:03:38PM +0900, Michael Paquier wrote:
> Indeed. I have reworked the whole, rather than just those three
> sentences.
So, any particular feelings about this patch? This has been around
for a couple of months/years now, so it could be a good time to do the
switch now rather than wait an extra year, or even the beginning of
the next release cycle. And the buildfarm is already able to handle
that in its code based on the last release, by skipping the upgrade
check if it finds a pg_upgrade/t/ subdirectory.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-03-31 05:00 ` Tom Lane <[email protected]>
2022-03-31 05:25 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
0 siblings, 2 replies; 118+ messages in thread
From: Tom Lane @ 2022-03-31 05:00 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
Michael Paquier <[email protected]> writes:
> So, any particular feelings about this patch? This has been around
> for a couple of months/years now, so it could be a good time to do the
> switch now rather than wait an extra year, or even the beginning of
> the next release cycle. And the buildfarm is already able to handle
> that in its code based on the last release, by skipping the upgrade
> check if it finds a pg_upgrade/t/ subdirectory.
There's still about a third of the buildfarm running older
client releases --- I count
2 REL_8
2 REL_10
13 REL_11
6 REL_12
16 REL_13.1
89 REL_14
How well does this patch work with pre-14 buildfarm clients?
regards, tom lane
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
@ 2022-03-31 05:25 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 118+ messages in thread
From: Tom Lane @ 2022-03-31 05:25 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
I wrote:
> There's still about a third of the buildfarm running older
> client releases --- I count
> 2 REL_8
> 2 REL_10
> 13 REL_11
> 6 REL_12
> 16 REL_13.1
> 89 REL_14
Wait a minute ... actually, what's most relevant here is
the population running TAP tests, which seems to be
2 REL_8
4 REL_11
1 REL_12
7 REL_13.1
53 REL_14
So there are still some people we'd have to nag if it doesn't
work pre-v14, but fewer than I thought --- specifically,
the owners of
butterflyfish
copperhead
eelpout
elver
halibut
kittiwake
mantid
marabou
massasauga
myna
snakefly
snapper
spurfowl
tadarida
regards, tom lane
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
@ 2022-03-31 05:36 ` Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
1 sibling, 1 reply; 118+ messages in thread
From: Andres Freund @ 2022-03-31 05:36 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Michael Paquier <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On 2022-03-31 01:00:14 -0400, Tom Lane wrote:
> How well does this patch work with pre-14 buildfarm clients?
Looks to me like it'll just run the test twice, once via TestUpgrade, once via
taptest. It's possible that there could be trouble somehow due to duplicated
log files or something?
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
@ 2022-03-31 07:56 ` Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-03-31 07:56 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Wed, Mar 30, 2022 at 10:36:16PM -0700, Andres Freund wrote:
> On 2022-03-31 01:00:14 -0400, Tom Lane wrote:
> > How well does this patch work with pre-14 buildfarm clients?
>
> Looks to me like it'll just run the test twice, once via TestUpgrade, once via
> taptest. It's possible that there could be trouble somehow due to duplicated
> log files or something?
Hmm. TestUpgrade.pm also uses tmp_check/, and the TAP tests would
remove this path before running. Still, all the contents of the logs
would be printed out before moving to the next tests at the end of
check-pg_upgrade. It does not seem like this double run is going to
be an issue on this side.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-03-31 13:49 ` Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Tom Lane @ 2022-03-31 13:49 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
Michael Paquier <[email protected]> writes:
> On Wed, Mar 30, 2022 at 10:36:16PM -0700, Andres Freund wrote:
>> On 2022-03-31 01:00:14 -0400, Tom Lane wrote:
>>> How well does this patch work with pre-14 buildfarm clients?
>> Looks to me like it'll just run the test twice, once via TestUpgrade, once via
>> taptest. It's possible that there could be trouble somehow due to duplicated
>> log files or something?
> Hmm. TestUpgrade.pm also uses tmp_check/, and the TAP tests would
> remove this path before running. Still, all the contents of the logs
> would be printed out before moving to the next tests at the end of
> check-pg_upgrade. It does not seem like this double run is going to
> be an issue on this side.
Well, let's go ahead with it and see what happens. If it's too
much of a mess we can always revert.
regards, tom lane
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
@ 2022-04-01 01:16 ` Michael Paquier <[email protected]>
2022-04-01 03:54 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-01 04:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-01 06:01 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-02 07:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 5 replies; 118+ messages in thread
From: Michael Paquier @ 2022-04-01 01:16 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Thu, Mar 31, 2022 at 09:49:50AM -0400, Tom Lane wrote:
> Well, let's go ahead with it and see what happens. If it's too
> much of a mess we can always revert.
Okay, done after an extra round of self-review. I have finished by
tweaking a couple of comments, and adjusted further TESTING to explain
what needs to be done to have a dump compatible with the test. Let's
now see what goes wrong.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-04-01 03:54 ` Michael Paquier <[email protected]>
4 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2022-04-01 03:54 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Noah Misch <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote:
> Okay, done after an extra round of self-review. I have finished by
> tweaking a couple of comments, and adjusted further TESTING to explain
> what needs to be done to have a dump compatible with the test. Let's
> now see what goes wrong.
So, the first reports are published, and the buildfarm is rather cool
on the matter. wrasse is the only buildfarm member that has reported
a failure, complaining that the dumps generated do not match. I am
not completely sure what's going on there, so I have applied an extra
patch to get more information from the logs on failures, and switched
the test to use File::Compare::compare() to check if the dumps match.
This last part feels safer in the long run, anyway. There should be a
diff command as previous runs used test.sh, so perhaps this is an
issue with its perl. The next report should tell more.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-04-01 04:00 ` Michael Paquier <[email protected]>
4 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2022-04-01 04:00 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Thu, Mar 31, 2022 at 08:42:41PM -0700, Noah Misch wrote:
> The failure looked like this:
>
> # Running: diff -q /export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/tmp_test_lPFv/dump1.sql /export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/tmp_test_lPFv/dump2.sql
> /usr/bin/diff: illegal option -- q
> usage: diff [-bitw] [-c | -e | -f | -h | -n | -u] file1 file2
> diff [-bitw] [-C number | -U number] file1 file2
> diff [-bitw] [-D string] file1 file2
> diff [-bitw] [-c | -e | -f | -h | -n | -u] [-l] [-r] [-s] [-S name] directory1 directory2
> not ok 4 - old and new dump match after pg_upgrade
Ah, thanks for the information! So the problem was that the first
commit of the patch took the diff command from the MSVC scripts, and
there is no -q on Solaris 11.3. Using File::Compare should be enough
to fix the problem, then. Hopefully.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../YkZ41Kx16%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-04-01 06:01 ` Michael Paquier <[email protected]>
2022-04-01 11:53 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
4 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-04-01 06:01 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]
On Thu, Mar 31, 2022 at 10:51:59PM -0500, Justin Pryzby wrote:
> Is diff -q defined somewhere ? I can't find it in postgres sources nor in
> sources for bf client.
322becb has added such a call, at the end of 002_pg_upgrade.pl.
vcregress.pl also has one before this commit.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../YkaVQo44WFTAF2%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-01 06:01 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-04-01 11:53 ` Michael Paquier <[email protected]>
2022-04-02 03:10 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-04-01 11:53 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]
On Fri, Apr 01, 2022 at 03:01:38PM +0900, Michael Paquier wrote:
> On Thu, Mar 31, 2022 at 10:51:59PM -0500, Justin Pryzby wrote:
>> Is diff -q defined somewhere ? I can't find it in postgres sources nor in
>> sources for bf client.
>
> 322becb has added such a call, at the end of 002_pg_upgrade.pl.
> vcregress.pl also has one before this commit.
The Windows animals seem to be in good shape, except hamerkop that
dies on "vcregress upgradecheck" when the TAP tests are disabled
causing the buildfarm client to stop. My idea to use upgradecheck
leads to more code than just moving the test to bincheck so let's
reuse the suggestion from Andres upthread and disable completely
upgradecheck, keeping the target around only for compatibility. The
attached does that, and the test of pg_upgrade would go through
bincheck instead.
It is late here, I'll try to get that patched up tomorrow.
--
Michael
Attachments:
[text/x-diff] win32-upgradecheck.patch (1.5K, ../../[email protected]/2-win32-upgradecheck.patch)
download | inline diff:
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 43d05bde4e..18101e7a70 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -470,7 +470,6 @@ $ENV{CONFIG}="Debug";
<userinput>vcregress isolationcheck</userinput>
<userinput>vcregress bincheck</userinput>
<userinput>vcregress recoverycheck</userinput>
-<userinput>vcregress upgradecheck</userinput>
</screen>
To change the schedule used (default is parallel), append it to the
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index e896820ac5..fbfc781508 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -106,7 +106,7 @@ my %command = (
ISOLATIONCHECK => \&isolationcheck,
BINCHECK => \&bincheck,
RECOVERYCHECK => \&recoverycheck,
- UPGRADECHECK => \&upgradecheck,
+ UPGRADECHECK => \&upgradecheck, # no-op
TAPTEST => \&taptest,);
my $proc = $command{$what};
@@ -286,9 +286,6 @@ sub bincheck
foreach my $dir (@bin_dirs)
{
next unless -d "$dir/t";
- # Do not consider pg_upgrade, as it is handled by
- # upgradecheck.
- next if ($dir =~ "/pg_upgrade/");
my $status = tap_check($dir);
$mstat ||= $status;
@@ -520,9 +517,9 @@ sub generate_db
sub upgradecheck
{
- InstallTemp();
- my $mstat = tap_check("$topdir/src/bin/pg_upgrade");
- exit $mstat if $mstat;
+ # pg_upgrade is now handled by bincheck, but keep this
+ # target for backward compatibility.
+ print "upgradecheck disabled\n";
return;
}
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-01 06:01 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-01 11:53 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-04-02 03:10 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2022-04-02 03:10 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; [email protected]
On Fri, Apr 01, 2022 at 08:34:34AM -0500, Justin Pryzby wrote:
> If you do that, should also remove upgradecheck from .cirrus.yaml, which
> currently runs the upgradecheck target.
Indeed. It makes no sense to keep that. I have removed this part and
applied the patch, after one extra run through the CI.
> An alternative to your patch to have the buildfarm client avoid calling
> upgradecheck if tap tests are disabled. Under your patch, upgrade check is a
> NOP, so it should stop calling upgradecheck anyway. So maybe this is a better
> option ?
Yeah, there is an extra issue with the buildfarm client here. The
animals that have TAP enabled are now running the tests of pg_upgrade
twice: once per the optional module TestUpgrade and once in
run_bin_tests()@run_build.pl. This is something that needs to be
changed in the client code itself, and maybe the best fix is to
disable TestUpgrade.pm when running with v15~ or a newer version. A
fix with this approach would become much easier once REL_15_STABLE is
created, though. I am pretty sure that it should also be possible to
change the list of optional modules depending on the branch running,
but I have not dug into that..
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-05-02 07:00 ` Michael Paquier <[email protected]>
4 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2022-05-02 07:00 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Sun, May 01, 2022 at 09:27:18PM -0700, Noah Misch wrote:
> commit 322becb wrote:
Thanks, Noah. I am out this week, but I should be able to address all
your points at the beginning of next week. I have added an open item
for now.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-05-09 03:18 ` Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
4 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-05-09 03:18 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Sun, May 01, 2022 at 09:27:18PM -0700, Noah Misch wrote:
> On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote:
>> commit 322becb wrote:
>
> Nothing checks the command result, so the test file passes even if each of
> these createdb calls fails. Other run_log() calls in this file have the same
> problem. This particular one should be command_ok() or similar.
All of them could rely on command_ok(), as they should never fail, so
switched this way.
> --host and --port are redundant in a PostgreSQL::Test::Cluster::run_log call,
> because that call puts equivalent configuration in the environment. Other
> calls in the file have the same redundant operands. (No other test file has
> redundant --host or --port.)
Right. Removed all that.
>> + # Grab any regression options that may be passed down by caller.
>> + my $extra_opts_val = $ENV{EXTRA_REGRESS_OPT} || "";
>
> Typo: s/_OPT/_OPTS/
Oops, fixed.
>> + my @extra_opts = split(/\s+/, $extra_opts_val);
>
> src/test/recovery/t/027_stream_regress.pl and the makefiles treat
> EXTRA_REGRESS_OPTS as a shell fragment. To be compatible, use the
> src/test/recovery/t/027_stream_regress.pl approach. Affected usage patetrns
> are not very important, but since the tree has code for it, you may as well
> borrow that code. These examples witness the difference:
So the pattern of EXTRA_REGRESS_OPTS being used in the Makefiles is
the decision point here. Makes sense.
>> -# Create databases with names covering the ASCII bytes other than NUL, BEL,
>> -# LF, or CR. BEL would ring the terminal bell in the course of this test, and
>> -# it is not otherwise a special case. PostgreSQL doesn't support the rest.
>> -dbname1=`awk 'BEGIN { for (i= 1; i < 46; i++)
>> - if (i != 7 && i != 10 && i != 13) printf "%c", i }' </dev/null`
>> -# Exercise backslashes adjacent to double quotes, a Windows special case.
>> -dbname1='\"\'$dbname1'\\"\\\'
>
> This rewrite dropped the exercise of backslashes adjacent to double quotes.
Damn, thanks. If I am reading that right, this could be done with the
following addition in generate_db(), adding double quotes surrounded
by backslashes before and after the database name:
$dbname = '\\"\\' . $dbname . '\\"\\';
All these fixes lead me to the attached patch. Does that look fine to
you?
Thanks,
--
Michael
Attachments:
[text/x-diff] upgrade-tap-fixes-noah.patch (3.3K, ../../[email protected]/2-upgrade-tap-fixes-noah.patch)
download | inline diff:
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
index 05bf161843..4002982dc0 100644
--- a/src/bin/pg_upgrade/t/002_pg_upgrade.pl
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -21,9 +21,11 @@ sub generate_db
next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
$dbname = $dbname . sprintf('%c', $i);
}
- $node->run_log(
- [ 'createdb', '--host', $node->host, '--port', $node->port, $dbname ]
- );
+
+ # Exercise backslashes adjacent to double quotes, a Windows special
+ # case.
+ $dbname = '\\"\\' . $dbname . '\\"\\';
+ $node->command_ok([ 'createdb', $dbname ]);
}
# The test of pg_upgrade requires two clusters, an old one and a new one
@@ -70,12 +72,7 @@ if (defined($ENV{olddump}))
# Load the dump using the "postgres" database as "regression" does
# not exist yet, and we are done here.
- $oldnode->command_ok(
- [
- 'psql', '-X', '-f', $olddumpfile,
- '--port', $oldnode->port, '--host', $oldnode->host,
- 'postgres'
- ]);
+ $oldnode->command_ok([ 'psql', '-X', '-f', $olddumpfile, 'postgres' ]);
}
else
{
@@ -87,8 +84,7 @@ else
generate_db($oldnode, 91, 127);
# Grab any regression options that may be passed down by caller.
- my $extra_opts_val = $ENV{EXTRA_REGRESS_OPT} || "";
- my @extra_opts = split(/\s+/, $extra_opts_val);
+ my $extra_opts = $ENV{EXTRA_REGRESS_OPTS} || "";
# --dlpath is needed to be able to find the location of regress.so
# and any libraries the regression tests require.
@@ -100,19 +96,19 @@ else
# --inputdir points to the path of the input files.
my $inputdir = "$srcdir/src/test/regress";
- my @regress_command = [
- $ENV{PG_REGRESS}, @extra_opts,
- '--dlpath', $dlpath,
- '--max-concurrent-tests', '20',
- '--bindir=', '--host',
- $oldnode->host, '--port',
- $oldnode->port, '--schedule',
- "$srcdir/src/test/regress/parallel_schedule", '--outputdir',
- $outputdir, '--inputdir',
- $inputdir
- ];
-
- my $rc = run_log(@regress_command);
+ my $rc =
+ system($ENV{PG_REGRESS}
+ . "$extra_opts "
+ . "--dlpath=\"$dlpath\" "
+ . "--bindir= "
+ . "--host="
+ . $oldnode->host . " "
+ . "--port="
+ . $oldnode->port . " "
+ . "--schedule=$srcdir/src/test/regress/parallel_schedule "
+ . "--max-concurrent-tests=20 "
+ . "--inputdir=\"$inputdir\" "
+ . "--outputdir=\"$outputdir\"");
if ($rc != 0)
{
# Dump out the regression diffs file, if there is one
@@ -133,12 +129,10 @@ if (defined($ENV{oldinstall}))
{
# Note that upgrade_adapt.sql from the new version is used, to
# cope with an upgrade to this version.
- $oldnode->run_log(
+ $oldnode->command_ok(
[
- 'psql', '-X',
- '-f', "$srcdir/src/bin/pg_upgrade/upgrade_adapt.sql",
- '--port', $oldnode->port,
- '--host', $oldnode->host,
+ 'psql', '-X',
+ '-f', "$srcdir/src/bin/pg_upgrade/upgrade_adapt.sql",
'regression'
]);
}
@@ -232,7 +226,7 @@ if (-d $log_path)
}
# Second dump from the upgraded instance.
-$newnode->run_log(
+$newnode->command_ok(
[
'pg_dumpall', '--no-sync',
'-d', $newnode->connstr('postgres'),
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-05-11 01:29 ` Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-05-11 01:29 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Mon, May 09, 2022 at 12:18:39PM +0900, Michael Paquier wrote:
> All these fixes lead me to the attached patch.
I have applied this stuff as of 7dd3ee5, in time for beta1, and closed
the open item. One difference is that I've added one backslash
surrounding the double quote at the beginning *and* the end of the
database name in the patch. However, the original case was different,
with:
- At the beginning of the database name, one backslash before and
after the double quote.
- At the end of the database name, two backslaces before the double
quote and three after the double quote.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-05-11 05:32 ` Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Noah Misch @ 2022-05-11 05:32 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Wed, May 11, 2022 at 10:29:44AM +0900, Michael Paquier wrote:
> On Mon, May 09, 2022 at 12:18:39PM +0900, Michael Paquier wrote:
> > All these fixes lead me to the attached patch.
>
> I have applied this stuff as of 7dd3ee5, in time for beta1, and closed
> the open item. One difference is that I've added one backslash
> surrounding the double quote at the beginning *and* the end of the
> database name in the patch. However, the original case was different,
> with:
> - At the beginning of the database name, one backslash before and
> after the double quote.
> - At the end of the database name, two backslaces before the double
> quote and three after the double quote.
Why did you discontinue testing the longstanding test database name?
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
@ 2022-05-12 05:27 ` Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-05-12 05:27 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Tue, May 10, 2022 at 10:32:55PM -0700, Noah Misch wrote:
> Why did you discontinue testing the longstanding test database name?
I am not sure what you mean here. Are you saying that the test should
be changed to prefix each database name by "regression", as it was the
case in test.sh? Or do you mean that the backslash/double-quote
business should only apply to the first database name and not the
other two, implying that the new generate_db() in 002_pg_upgrade.pl
had better have a $prefix and a $suffix like it was originally
written?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-05-14 08:27 ` Noah Misch <[email protected]>
2022-05-16 05:30 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Noah Misch @ 2022-05-14 08:27 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Thu, May 12, 2022 at 02:27:30PM +0900, Michael Paquier wrote:
> On Tue, May 10, 2022 at 10:32:55PM -0700, Noah Misch wrote:
> > On Wed, May 11, 2022 at 10:29:44AM +0900, Michael Paquier wrote:
> > > On Mon, May 09, 2022 at 12:18:39PM +0900, Michael Paquier wrote:
> > > > All these fixes lead me to the attached patch.
> > >
> > > I have applied this stuff as of 7dd3ee5, in time for beta1, and closed
> > > the open item. One difference is that I've added one backslash
> > > surrounding the double quote at the beginning *and* the end of the
> > > database name in the patch. However, the original case was different,
> > > with:
> > > - At the beginning of the database name, one backslash before and
> > > after the double quote.
> > > - At the end of the database name, two backslaces before the double
> > > quote and three after the double quote.
Here, you describe differences between test.sh and your rewrite of test.sh.
> > Why did you discontinue testing the longstanding test database name?
>
> I am not sure what you mean here.
Here, I requested the rationale for the differences you had just described.
You made a choice to stop testing one list of database names and start testing
a different list of database names. Why?
> Are you saying that the test should
> be changed to prefix each database name by "regression", as it was the
> case in test.sh? Or do you mean that the backslash/double-quote
> business should only apply to the first database name and not the
> other two, implying that the new generate_db() in 002_pg_upgrade.pl
> had better have a $prefix and a $suffix like it was originally
> written?
No, I wasn't saying any of those. (Later, I may say one or more of those.)
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
@ 2022-05-16 05:30 ` Michael Paquier <[email protected]>
2022-05-18 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-05-16 05:30 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Sat, May 14, 2022 at 01:27:28AM -0700, Noah Misch wrote:
> Here, I requested the rationale for the differences you had just described.
> You made a choice to stop testing one list of database names and start testing
> a different list of database names. Why?
Because the shape of the new names does not change the test coverage
("regression" prefix or the addition of the double quotes with
backslashes for all the database names), while keeping the code a bit
simpler. If you think that the older names are more adapted, I have
no objections to use them, FWIW, which is something like the patch
attached would achieve.
This uses the same convention as vcregress.pl before 322becb, but not
the one of test.sh where "regression" was appended to the database
names.
--
Michael
Attachments:
[text/x-diff] upgrade-tap-fixes-noah-2.patch (1.5K, ../../[email protected]/2-upgrade-tap-fixes-noah-2.patch)
download | inline diff:
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
index 8372a85e6e..33a75991d8 100644
--- a/src/bin/pg_upgrade/t/002_pg_upgrade.pl
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -13,18 +13,16 @@ use Test::More;
# Generate a database with a name made of a range of ASCII characters.
sub generate_db
{
- my ($node, $from_char, $to_char) = @_;
+ my ($node, $prefix, $from_char, $to_char, $suffix) = @_;
- my $dbname = '';
+ my $dbname = $prefix;
for my $i ($from_char .. $to_char)
{
next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
$dbname = $dbname . sprintf('%c', $i);
}
- # Exercise backslashes adjacent to double quotes, a Windows special
- # case.
- $dbname = '\\"\\' . $dbname . '\\\\"\\\\\\';
+ $dbname .= $suffix;
$node->command_ok([ 'createdb', $dbname ]);
}
@@ -79,10 +77,12 @@ else
{
# Default is to use pg_regress to set up the old instance.
- # Create databases with names covering most ASCII bytes
- generate_db($oldnode, 1, 45);
- generate_db($oldnode, 46, 90);
- generate_db($oldnode, 91, 127);
+ # Create databases with names covering most ASCII bytes. The
+ # first name exercises backslashes adjacent to double quotes, a
+ # Windows special case.
+ generate_db($oldnode, "\\\"\\", 1, 45, "\\\\\"\\\\\\");
+ generate_db($oldnode, '', 46, 90, '');
+ generate_db($oldnode, '', 91, 127, '');
# Grab any regression options that may be passed down by caller.
my $extra_opts = $ENV{EXTRA_REGRESS_OPTS} || "";
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-16 05:30 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-05-18 08:03 ` Noah Misch <[email protected]>
2022-05-18 09:20 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Noah Misch @ 2022-05-18 08:03 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Mon, May 16, 2022 at 02:30:00PM +0900, Michael Paquier wrote:
> On Sat, May 14, 2022 at 01:27:28AM -0700, Noah Misch wrote:
> > Here, I requested the rationale for the differences you had just described.
> > You made a choice to stop testing one list of database names and start testing
> > a different list of database names. Why?
>
> Because the shape of the new names does not change the test coverage
> ("regression" prefix or the addition of the double quotes with
> backslashes for all the database names), while keeping the code a bit
> simpler. If you think that the older names are more adapted, I have
> no objections to use them, FWIW, which is something like the patch
> attached would achieve.
>
> This uses the same convention as vcregress.pl before 322becb, but not
> the one of test.sh where "regression" was appended to the database
> names.
I would have picked the test.sh names, both because test.sh was the senior
implementation and because doing so avoids warnings under
-DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS. See the warnings here:
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=longfin&dt=2022-05-18%2000%3A59%3A...
More-notable line from that same log:
sh: /Users/buildfarm/bf-data/HEAD/pgsql.build/src/bin/pg_upgrade/../../../src/test/regress/pg_regress--port=5678: No such file or directory
Commit 7dd3ee5 adopted much of the 027_stream_regress.pl approach to running
pg_regress, but it didn't grab the "is($rc, 0, 'regression tests pass')"
needed to make defects like that report a failure.
> --- a/src/bin/pg_upgrade/t/002_pg_upgrade.pl
> +++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
> @@ -13,18 +13,16 @@ use Test::More;
> # Generate a database with a name made of a range of ASCII characters.
> sub generate_db
> {
> - my ($node, $from_char, $to_char) = @_;
> + my ($node, $prefix, $from_char, $to_char, $suffix) = @_;
>
> - my $dbname = '';
> + my $dbname = $prefix;
> for my $i ($from_char .. $to_char)
> {
> next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
> $dbname = $dbname . sprintf('%c', $i);
> }
>
> - # Exercise backslashes adjacent to double quotes, a Windows special
> - # case.
> - $dbname = '\\"\\' . $dbname . '\\\\"\\\\\\';
> + $dbname .= $suffix;
> $node->command_ok([ 'createdb', $dbname ]);
> }
>
> @@ -79,10 +77,12 @@ else
> {
> # Default is to use pg_regress to set up the old instance.
>
> - # Create databases with names covering most ASCII bytes
> - generate_db($oldnode, 1, 45);
> - generate_db($oldnode, 46, 90);
> - generate_db($oldnode, 91, 127);
> + # Create databases with names covering most ASCII bytes. The
> + # first name exercises backslashes adjacent to double quotes, a
> + # Windows special case.
> + generate_db($oldnode, "\\\"\\", 1, 45, "\\\\\"\\\\\\");
> + generate_db($oldnode, '', 46, 90, '');
> + generate_db($oldnode, '', 91, 127, '');
Does this pass on Windows? I'm 65% confident that released IPC::Run can't
handle this input due to https://github.com/toddr/IPC-Run/issues/142. If it's
passing for you on Windows, then disregard.
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-16 05:30 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-18 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
@ 2022-05-18 09:20 ` Michael Paquier <[email protected]>
2022-05-21 01:28 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-05-18 09:20 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Wed, May 18, 2022 at 01:03:15AM -0700, Noah Misch wrote:
> On Mon, May 16, 2022 at 02:30:00PM +0900, Michael Paquier wrote:
>> Because the shape of the new names does not change the test coverage
>> ("regression" prefix or the addition of the double quotes with
>> backslashes for all the database names), while keeping the code a bit
>> simpler. If you think that the older names are more adapted, I have
>> no objections to use them, FWIW, which is something like the patch
>> attached would achieve.
>>
>> This uses the same convention as vcregress.pl before 322becb, but not
>> the one of test.sh where "regression" was appended to the database
>> names.
>
> I would have picked the test.sh names, both because test.sh was the senior
> implementation and because doing so avoids warnings under
> -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS. See the warnings here:
> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=longfin&dt=2022-05-18%2000%3A59%3A...
Yes, I saw that. This did not bother me much as the TAP tests run in
isolation, but I am fine to stick to your option and silence these.
> More-notable line from that same log:
> sh: /Users/buildfarm/bf-data/HEAD/pgsql.build/src/bin/pg_upgrade/../../../src/test/regress/pg_regress--port=5678: No such file or directory
So you are using EXTRA_REGRESS_OPTS, then, and a space is missing from
the first argument of the command used to make that work properly.
> Commit 7dd3ee5 adopted much of the 027_stream_regress.pl approach to running
> pg_regress, but it didn't grab the "is($rc, 0, 'regression tests pass')"
> needed to make defects like that report a failure.
Okay, added this one.
>> + generate_db($oldnode, "\\\"\\", 1, 45, "\\\\\"\\\\\\");
>> + generate_db($oldnode, '', 46, 90, '');
>> + generate_db($oldnode, '', 91, 127, '');
>
> Does this pass on Windows? I'm 65% confident that released IPC::Run can't
> handle this input due to https://github.com/toddr/IPC-Run/issues/142. If it's
> passing for you on Windows, then disregard.
Hmm. The CI has been passing for me with this name pattern in place,
as of https://github.com/michaelpq/postgres/tree/upgrade_tap_fixes.
Attached is an updated patch to address your concerns.
--
Michael
Attachments:
[text/x-diff] upgrade-tap-fixes-noah-3.patch (1.9K, ../../[email protected]/2-upgrade-tap-fixes-noah-3.patch)
download | inline diff:
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
index 8372a85e6e..86fe1b4d09 100644
--- a/src/bin/pg_upgrade/t/002_pg_upgrade.pl
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -13,18 +13,16 @@ use Test::More;
# Generate a database with a name made of a range of ASCII characters.
sub generate_db
{
- my ($node, $from_char, $to_char) = @_;
+ my ($node, $prefix, $from_char, $to_char, $suffix) = @_;
- my $dbname = '';
+ my $dbname = $prefix;
for my $i ($from_char .. $to_char)
{
next if $i == 7 || $i == 10 || $i == 13; # skip BEL, LF, and CR
$dbname = $dbname . sprintf('%c', $i);
}
- # Exercise backslashes adjacent to double quotes, a Windows special
- # case.
- $dbname = '\\"\\' . $dbname . '\\\\"\\\\\\';
+ $dbname .= $suffix;
$node->command_ok([ 'createdb', $dbname ]);
}
@@ -79,10 +77,12 @@ else
{
# Default is to use pg_regress to set up the old instance.
- # Create databases with names covering most ASCII bytes
- generate_db($oldnode, 1, 45);
- generate_db($oldnode, 46, 90);
- generate_db($oldnode, 91, 127);
+ # Create databases with names covering most ASCII bytes. The
+ # first name exercises backslashes adjacent to double quotes, a
+ # Windows special case.
+ generate_db($oldnode, 'regression\\"\\', 1, 45, '\\\\"\\\\\\');
+ generate_db($oldnode, 'regression', 46, 90, '');
+ generate_db($oldnode, 'regression', 91, 127, '');
# Grab any regression options that may be passed down by caller.
my $extra_opts = $ENV{EXTRA_REGRESS_OPTS} || "";
@@ -99,7 +99,7 @@ else
my $rc =
system($ENV{PG_REGRESS}
- . "$extra_opts "
+ . " $extra_opts "
. "--dlpath=\"$dlpath\" "
. "--bindir= "
. "--host="
@@ -121,6 +121,7 @@ else
print "=== EOF ===\n";
}
}
+ is($rc, 0, 'regression tests pass');
}
# Before dumping, get rid of objects not existing or not supported in later
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-16 05:30 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-18 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-18 09:20 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-05-21 01:28 ` Noah Misch <[email protected]>
2022-05-21 03:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Noah Misch @ 2022-05-21 01:28 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Wed, May 18, 2022 at 06:20:08PM +0900, Michael Paquier wrote:
> Attached is an updated patch to address your concerns.
Looks successful.
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-16 05:30 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-18 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-18 09:20 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-21 01:28 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
@ 2022-05-21 03:03 ` Michael Paquier <[email protected]>
2022-06-03 19:53 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-05-21 03:03 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: Tom Lane <[email protected]>; Andres Freund <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Fri, May 20, 2022 at 06:28:01PM -0700, Noah Misch wrote:
> Looks successful.
Thanks a lot for confirming. I have applied that on HEAD, then.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../YohWm%[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-16 05:30 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-18 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-18 09:20 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-21 01:28 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-21 03:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-06-03 19:53 ` Andres Freund <[email protected]>
2022-06-04 03:35 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Andres Freund @ 2022-06-03 19:53 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
Hi,
I just saw a pg_upgrade failure on my aio branch [1]. Not sure what caused it
yet. The reason I'm writing in this thread is that I looked at the
regress_log_* for the failure, and found it to be 14.95MiB (which crashed the
browser on my phone...).
https://api.cirrus-ci.com/v1/artifact/task/5167740683026432/log/src/bin/pg_upgrade/tmp_check/log/reg...
That seems way beyond reasonable.
regress_log_002_pg_upgrade.log includes all of 002_pg_upgrade_old_node.log and
002_pg_upgrade_new_node.log. The old node's log includes all pg_dump queries.
Followed by many MB of diff due to
=== diff of /Users/admin/pgsql/src/bin/pg_upgrade/tmp_check/tmp_test_Q7GQ/dump1.sql and /Users/admin/pgsql/src/bin/pg_upgrade/tmp_check/tmp_test_Q7GQ/dump2.sql
=== stdout ===
Greetings,
Andres Freund
[1] https://cirrus-ci.com/task/5167740683026432
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-16 05:30 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-18 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-18 09:20 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-21 01:28 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-21 03:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-06-03 19:53 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
@ 2022-06-04 03:35 ` Michael Paquier <[email protected]>
2022-06-06 04:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
0 siblings, 1 reply; 118+ messages in thread
From: Michael Paquier @ 2022-06-04 03:35 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Fri, Jun 03, 2022 at 12:53:18PM -0700, Andres Freund wrote:
> [...]
TRAP: FailedAssertion("AmIoWorkerProcess()", File: "xlog.c", Line:
4860, PID: 35325)
> regress_log_002_pg_upgrade.log includes all of 002_pg_upgrade_old_node.log and
> 002_pg_upgrade_new_node.log. The old node's log includes all pg_dump queries.
log_statement = all is the part biting here. It does not seem like
we'd lose a lot of context even if this is made less verbose.
> Followed by many MB of diff due to
>
> === diff of /Users/admin/pgsql/src/bin/pg_upgrade/tmp_check/tmp_test_Q7GQ/dump1.sql and /Users/admin/pgsql/src/bin/pg_upgrade/tmp_check/tmp_test_Q7GQ/dump2.sql
> === stdout ===
Something like 80~85% of the bloat comes from the diffs in your case.
Well, it is always possible to limit that to an arbitrary amount of
characters (say 50k~100k?) to still give some context, and dump the
whole in a different file outside the log/ path (aka tmp_check/), so
that the buildfarm would show a minimum amount of information, while
local failures would still have an access to everything.
Do you have any preferences?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-16 05:30 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-18 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-18 09:20 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-21 01:28 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-21 03:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-06-03 19:53 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-06-04 03:35 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
@ 2022-06-06 04:58 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Michael Paquier @ 2022-06-06 04:58 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Noah Misch <[email protected]>; Tom Lane <[email protected]>; Thomas Munro <[email protected]>; Julien Rouhaud <[email protected]>; Andrew Dunstan <[email protected]>; Postgres hackers <[email protected]>
On Sat, Jun 04, 2022 at 12:35:45PM +0900, Michael Paquier wrote:
> Something like 80~85% of the bloat comes from the diffs in your case.
> Well, it is always possible to limit that to an arbitrary amount of
> characters (say 50k~100k?) to still give some context, and dump the
> whole in a different file outside the log/ path (aka tmp_check/), so
> that the buildfarm would show a minimum amount of information, while
> local failures would still have an access to everything.
After looking a bit around that. Something like the attached, where
the characters are limited at 10k, would limit the output generated..
--
Michael
Attachments:
[text/x-diff] upgrade-tap-logs.patch (1.2K, ../../[email protected]/2-upgrade-tap-logs.patch)
download | inline diff:
diff --git a/src/bin/pg_upgrade/t/002_pg_upgrade.pl b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
index 55c7354ba2..4581ddc915 100644
--- a/src/bin/pg_upgrade/t/002_pg_upgrade.pl
+++ b/src/bin/pg_upgrade/t/002_pg_upgrade.pl
@@ -223,6 +223,9 @@ command_ok(
'run of pg_upgrade for new instance');
$newnode->start;
+# Limit all contents to 10k characters.
+my $report_max_chars = 10000;
+
# Check if there are any logs coming from pg_upgrade, that would only be
# retained on failure.
my $log_path = $newnode->data_dir . "/pg_upgrade_output.d/log";
@@ -231,7 +234,8 @@ if (-d $log_path)
foreach my $log (glob("$log_path/*"))
{
note "=== contents of $log ===\n";
- print slurp_file($log);
+ my $contents = slurp_file($log);
+ print substr($contents, 0, $report_max_chars);
print "=== EOF ===\n";
}
}
@@ -256,9 +260,9 @@ if ($compare_res != 0)
run_command([ 'diff', "$tempdir/dump1.sql", "$tempdir/dump2.sql" ]);
print "=== diff of $tempdir/dump1.sql and $tempdir/dump2.sql\n";
print "=== stdout ===\n";
- print $stdout;
+ print substr($stdout, 0, $report_max_chars);
print "=== stderr ===\n";
- print $stderr;
+ print substr($stderr, 0, $report_max_chars);
print "=== EOF ===\n";
}
[application/pgp-signature] signature.asc (833B, ../../[email protected]/3-signature.asc)
download
^ permalink raw reply [nested|flat] 118+ messages in thread
* [PATCH] Forgot to add copy support in f10a025cfe97
@ 2022-07-08 13:34 Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Alvaro Herrera @ 2022-07-08 13:34 UTC (permalink / raw)
---
src/backend/nodes/copyfuncs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
index 2c834e4d0d..b8a5715981 100644
--- a/src/backend/nodes/copyfuncs.c
+++ b/src/backend/nodes/copyfuncs.c
@@ -5978,11 +5978,12 @@ copyObjectImpl(const void *from)
break;
/*
- * Lists of integers and OIDs don't need to be deep-copied, so we
- * perform a shallow copy via list_copy()
+ * Lists of integers, OIDs and XIDs don't need to be deep-copied,
+ * so we perform a shallow copy via list_copy()
*/
case T_IntList:
case T_OidList:
+ case T_XidList:
retval = list_copy(from);
break;
--
2.30.2
--6yrbxhl5vhfbhz5a--
^ permalink raw reply [nested|flat] 118+ messages in thread
* Re: Improve the granularity of PQsocketPoll's timeout parameter?
@ 2024-06-11 06:55 Dominique Devienne <[email protected]>
0 siblings, 0 replies; 118+ messages in thread
From: Dominique Devienne @ 2024-06-11 06:55 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]; Tristan Partin <[email protected]>; Robert Haas <[email protected]>
On Mon, Jun 10, 2024 at 11:39 PM Tom Lane <[email protected]> wrote:
> The next question is how to spell "int64" in libpq-fe.h.
Hi. Out-of-curiosity, I grep'd for it in my 16.1 libpq:
[ddevienne@marsu include]$ grep 'long long' *.h
ecpg_config.h:/* Define to 1 if the system has the type `long long int'. */
ecpg_config.h:/* Define to 1 if `long long int' works and is 64 bits. */
pg_config.h:/* The normal alignment of `long long int', in bytes. */
pg_config.h:/* Define to 1 if `long long int' works and is 64 bits. */
pgtypes_interval.h:typedef long long int int64;
And the relevant snippet of pgtypes_interval.h is:
#ifdef HAVE_LONG_INT_64
#ifndef HAVE_INT64
typedef long int int64;
#endif
#elif defined(HAVE_LONG_LONG_INT_64)
#ifndef HAVE_INT64
typedef long long int int64;
#endif
#else
/* neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 */
#error must have a working 64-bit integer datatype
#endif
Given this precedent, can't the same be done?
And if a 64-bit integer is too troublesome, why not just two 32-bit
parameters instead?
Either a (time_t + int usec), microsecond offset, clamped to [0, 1M),
or (int sec + int usec)?
I'm fine with any portable solution that allows sub-second timeouts, TBH.
Just thinking aloud here. Thanks, --DD
^ permalink raw reply [nested|flat] 118+ messages in thread
end of thread, other threads:[~2024-06-11 06:55 UTC | newest]
Thread overview: 118+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-04-03 13:07 Rewriting the test of pg_upgrade as a TAP test Michael Paquier <[email protected]>
2017-04-03 13:12 ` Craig Ringer <[email protected]>
2017-04-03 15:12 ` Stephen Frost <[email protected]>
2017-04-03 22:28 ` Michael Paquier <[email protected]>
2017-04-03 22:38 ` Stephen Frost <[email protected]>
2017-04-03 23:51 ` Michael Paquier <[email protected]>
2017-04-04 12:30 ` Stephen Frost <[email protected]>
2017-04-05 02:28 ` Michael Paquier <[email protected]>
2017-04-05 13:24 ` Stephen Frost <[email protected]>
2017-04-05 22:48 ` Michael Paquier <[email protected]>
2017-04-14 06:00 ` Michael Paquier <[email protected]>
2017-04-14 11:03 ` Stephen Frost <[email protected]>
2017-04-14 12:22 ` Michael Paquier <[email protected]>
2017-04-14 12:24 ` Stephen Frost <[email protected]>
2017-09-06 13:05 ` Peter Eisentraut <[email protected]>
2017-09-06 13:52 ` Alvaro Herrera <[email protected]>
2017-09-06 14:44 ` Tom Lane <[email protected]>
2017-09-07 01:37 ` Michael Paquier <[email protected]>
2017-09-07 02:14 ` Michael Paquier <[email protected]>
2017-09-19 04:30 ` Michael Paquier <[email protected]>
2017-09-19 09:15 ` Alvaro Herrera <[email protected]>
2017-09-19 11:37 ` Michael Paquier <[email protected]>
2017-09-19 22:57 ` Peter Eisentraut <[email protected]>
2017-09-19 23:00 ` Michael Paquier <[email protected]>
2017-09-22 20:48 ` Peter Eisentraut <[email protected]>
2017-09-29 13:04 ` Peter Eisentraut <[email protected]>
2017-04-03 15:22 ` Peter Eisentraut <[email protected]>
2017-04-03 15:32 ` Andres Freund <[email protected]>
2017-04-04 13:52 ` Peter Eisentraut <[email protected]>
2017-04-05 02:30 ` Michael Paquier <[email protected]>
2017-04-05 13:52 ` Stephen Frost <[email protected]>
2017-04-05 14:15 ` Tom Lane <[email protected]>
2017-04-05 14:40 ` Stephen Frost <[email protected]>
2017-04-05 14:45 ` Andres Freund <[email protected]>
2017-04-05 14:50 ` Stephen Frost <[email protected]>
2017-04-05 15:01 ` Andres Freund <[email protected]>
2017-04-05 15:07 ` Stephen Frost <[email protected]>
2017-04-05 15:02 ` Tom Lane <[email protected]>
2017-04-05 15:13 ` Stephen Frost <[email protected]>
2017-04-06 01:30 ` Noah Misch <[email protected]>
2017-04-03 15:34 ` Stephen Frost <[email protected]>
2017-04-03 17:43 ` Andres Freund <[email protected]>
2017-04-03 17:55 ` Stephen Frost <[email protected]>
2018-01-26 08:00 Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-02 06:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andres Freund <[email protected]>
2018-03-02 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-02 13:11 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-02 14:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Alvaro Herrera <[email protected]>
2018-03-02 13:02 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-03 14:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-04 04:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-04 21:09 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Andrew Dunstan <[email protected]>
2018-03-06 20:13 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-03-06 21:12 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Tom Lane <[email protected]>
2018-03-21 14:51 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two David Steele <[email protected]>
2018-03-22 01:39 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-03-22 01:42 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Craig Ringer <[email protected]>
2018-03-22 01:49 ` Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-04-02 14:35 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Peter Eisentraut <[email protected]>
2018-04-03 06:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-04-09 00:38 ` Re: Rewriting the test of pg_upgrade as a TAP test - take two Michael Paquier <[email protected]>
2018-05-26 00:02 jsonb iterator not fully initialized Peter Eisentraut <[email protected]>
2018-05-26 07:09 ` Re: jsonb iterator not fully initialized Piotr Stefaniak <[email protected]>
2018-05-26 14:47 ` Re: jsonb iterator not fully initialized Andrew Dunstan <[email protected]>
2018-05-27 20:40 ` Re: jsonb iterator not fully initialized Dmitry Dolgov <[email protected]>
2021-05-15 02:26 Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-15 18:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-17 01:55 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-17 16:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-05-18 01:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-05-20 06:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-09-07 21:43 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Rachel Heaton <[email protected]>
2021-09-08 06:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-01 06:19 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-02 20:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-02 21:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 03:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-03 03:34 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2021-10-03 07:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-10 14:07 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Peter Eisentraut <[email protected]>
2021-10-11 00:40 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-11 13:04 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-12 04:48 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-10-03 12:22 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andrew Dunstan <[email protected]>
2021-10-12 04:45 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-12-14 02:08 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2021-12-14 05:31 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-12-14 06:14 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2021-12-15 01:47 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2021-12-16 02:51 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 04:10 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 05:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:25 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-03-31 05:36 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-03-31 07:56 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-03-31 13:49 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Tom Lane <[email protected]>
2022-04-01 01:16 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-01 03:54 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-01 04:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-01 06:01 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-01 11:53 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-04-02 03:10 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-02 07:00 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-09 03:18 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 01:29 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-11 05:32 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-12 05:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-14 08:27 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-16 05:30 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-18 08:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-18 09:20 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-05-21 01:28 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Noah Misch <[email protected]>
2022-05-21 03:03 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-06-03 19:53 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Andres Freund <[email protected]>
2022-06-04 03:35 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-06-06 04:58 ` Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set Michael Paquier <[email protected]>
2022-07-08 13:34 [PATCH] Forgot to add copy support in f10a025cfe97 Alvaro Herrera <[email protected]>
2024-06-11 06:55 Re: Improve the granularity of PQsocketPoll's timeout parameter? Dominique Devienne <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox