postgresql/src/bin/pg_upgrade/t/002_pg_upgrade.pl

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

350 lines
11 KiB
Perl
Raw Normal View History

Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
# Set of tests for pg_upgrade, including cross-version checks.
use strict;
use warnings;
use Cwd qw(abs_path);
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
use File::Basename qw(dirname);
use File::Compare;
Restructure pg_upgrade output directories for better idempotence 38bfae3 has moved the contents written to files by pg_upgrade under a new directory called pg_upgrade_output.d/ located in the new cluster's data folder, and it used a simple structure made of two subdirectories leading to a fixed structure: log/ and dump/. This design has made weaker pg_upgrade on repeated calls, as we could get failures when creating one or more of those directories, while potentially losing the logs of a previous run (logs are retained automatically on failure, and cleaned up on success unless --retain is specified). So a user would need to clean up pg_upgrade_output.d/ as an extra step for any repeated calls of pg_upgrade. The most common scenario here is --check followed by the actual upgrade, but one could see a failure when specifying an incorrect input argument value. Removing entirely the logs would have the disadvantage of removing all the past information, even if --retain was specified at some past step. This result is annoying for a lot of users and automated upgrade flows. So, rather than requiring a manual removal of pg_upgrade_output.d/, this redesigns the set of output directories in a more dynamic way, based on a suggestion from Tom Lane and Daniel Gustafsson. pg_upgrade_output.d/ is still the base path, but a second directory level is added, mostly named after an ISO-8601-formatted timestamp (in short human-readable, with milliseconds appended to the name to avoid any conflicts). The logs and dumps are saved within the same subdirectories as previously, as of log/ and dump/, but these are located inside the subdirectory named after the timestamp. The logs of a given run are removed only after a successful run if --retain is not used, and pg_upgrade_output.d/ is kept if there are any logs from a previous run. Note that previously, pg_upgrade would have kept the logs even after a successful --check but that was inconsistent compared to the case without --check when using --retain. The code in charge of the removal of the output directories is now refactored into a single routine. Two TAP tests are added with some --check commands (one failure case and one success case), to look after the issue fixed here. Note that the tests had to be tweaked a bit to fit with the new directory structure so as it can find any logs generated on failure. This is still going to require a change in the buildfarm client for the case where pg_upgrade is tested without the TAP test, though, but I'll tackle that with a separate patch where needed. Reported-by: Tushar Ahuja Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Justin Pryzby Discussion: https://postgr.es/m/77e6ecaa-2785-97aa-f229-4b6e047cbd2b@enterprisedb.com
2022-06-08 03:53:01 +02:00
use File::Find qw(find);
use File::Path qw(rmtree);
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
use PostgreSQL::Test::Cluster;
use PostgreSQL::Test::Utils;
use Test::More;
# Generate a database with a name made of a range of ASCII characters.
sub generate_db
{
my ($node, $prefix, $from_char, $to_char, $suffix) = @_;
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
my $dbname = $prefix;
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
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;
$node->command_ok(
[ 'createdb', $dbname ],
"created database with ASCII characters from $from_char to $to_char");
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
}
# Filter the contents of a dump before its use in a content comparison.
# This returns the path to the filtered dump.
sub filter_dump
{
my ($node, $dump_file) = @_;
my $dump_contents = slurp_file($dump_file);
# Remove the comments.
$dump_contents =~ s/^\-\-.*//mgx;
# Remove empty lines.
$dump_contents =~ s/^\n//mgx;
my $dump_file_filtered = "${dump_file}_filtered";
open(my $dh, '>', $dump_file_filtered)
|| die "opening $dump_file_filtered";
print $dh $dump_contents;
close($dh);
return $dump_file_filtered;
}
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
# The test of pg_upgrade requires two clusters, an old one and a new one
# that gets upgraded. Before running the upgrade, a logical dump of the
# old cluster is taken, and a second logical dump of the new one is taken
# after the upgrade. The upgrade test passes if there are no differences
# in these two dumps.
# Testing upgrades with an older version of PostgreSQL requires setting up
# two environment variables, as of:
# - "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 old cluster.
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";
}
# Paths to the dumps taken during the tests.
my $tempdir = PostgreSQL::Test::Utils::tempdir;
my $dump1_file = "$tempdir/dump1.sql";
my $dump2_file = "$tempdir/dump2.sql";
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
# Initialize node to upgrade
my $oldnode =
PostgreSQL::Test::Cluster->new('old_node',
install_path => $ENV{oldinstall});
# To increase coverage of non-standard segment size and group access without
# increasing test runtime, run these tests with a custom setting.
# --allow-group-access and --wal-segsize have been added in v11.
my %node_params = ();
$node_params{extra} = [ '--wal-segsize', '1', '--allow-group-access' ]
if $oldnode->pg_version >= 11;
$oldnode->init(%node_params);
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
$oldnode->start;
# The default location of the source code is the root of this directory.
my $srcdir = abs_path("../../..");
# Set up the data of the old instance with a dump or pg_regress.
if (defined($ENV{olddump}))
{
# Use the dump specified.
my $olddumpfile = $ENV{olddump};
die "no dump file found!" unless -e $olddumpfile;
# 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, 'postgres' ],
'loaded old dump file');
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
}
else
{
# Default is to use pg_regress to set up the old instance.
# 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, '');
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
# Grab any regression options that may be passed down by caller.
my $extra_opts = $ENV{EXTRA_REGRESS_OPTS} || "";
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
# --dlpath is needed to be able to find the location of regress.so
# and any libraries the regression tests require.
my $dlpath = dirname($ENV{REGRESS_SHLIB});
# --outputdir points to the path where to place the output files.
my $outputdir = $PostgreSQL::Test::Utils::tmp_check;
# --inputdir points to the path of the input files.
my $inputdir = "$srcdir/src/test/regress";
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
my $diffs = "$outputdir/regression.diffs";
if (-e $diffs)
{
print "=== dumping $diffs ===\n";
print slurp_file($diffs);
print "=== EOF ===\n";
}
}
is($rc, 0, 'regression tests pass');
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
}
# Initialize a new node for the upgrade.
my $newnode = PostgreSQL::Test::Cluster->new('new_node');
$newnode->init(%node_params);
my $newbindir = $newnode->config_data('--bindir');
my $oldbindir = $oldnode->config_data('--bindir');
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
# 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 major versions are used for the dump.
if (defined($ENV{oldinstall}))
{
# Note that upgrade_adapt.sql and psql from the new version are used,
# to cope with an upgrade to this version.
$newnode->command_ok(
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
[
'psql', '-X',
'-f', "$srcdir/src/bin/pg_upgrade/upgrade_adapt.sql",
'-d', $oldnode->connstr('regression'),
],
'ran adapt script');
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
}
# Take a dump before performing the upgrade as a base comparison. Note
# that we need to use pg_dumpall from the new node here.
my @dump_command = (
'pg_dumpall', '--no-sync', '-d', $oldnode->connstr('postgres'),
'-f', $dump1_file);
# --extra-float-digits is needed when upgrading from a version older than 11.
push(@dump_command, '--extra-float-digits', '0')
if ($oldnode->pg_version < 12);
$newnode->command_ok(\@dump_command, 'dump before running pg_upgrade');
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
# 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($dump1_file);
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
my $newregresssrc = "$srcdir/src/test/regress";
foreach (@libpaths)
{
my $libpath = $_;
$libpath = dirname($libpath);
$dump_data =~ s/$libpath/$newregresssrc/g;
}
open my $fh, ">", $dump1_file or die "could not open dump file";
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
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 databases
# 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/%'");
}
}
# In a VPATH build, we'll be started in the source directory, but we want
# to run pg_upgrade in the build directory so that any files generated finish
# in it, like delete_old_cluster.{sh,bat}.
chdir ${PostgreSQL::Test::Utils::tmp_check};
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
# Upgrade the instance.
$oldnode->stop;
Restructure pg_upgrade output directories for better idempotence 38bfae3 has moved the contents written to files by pg_upgrade under a new directory called pg_upgrade_output.d/ located in the new cluster's data folder, and it used a simple structure made of two subdirectories leading to a fixed structure: log/ and dump/. This design has made weaker pg_upgrade on repeated calls, as we could get failures when creating one or more of those directories, while potentially losing the logs of a previous run (logs are retained automatically on failure, and cleaned up on success unless --retain is specified). So a user would need to clean up pg_upgrade_output.d/ as an extra step for any repeated calls of pg_upgrade. The most common scenario here is --check followed by the actual upgrade, but one could see a failure when specifying an incorrect input argument value. Removing entirely the logs would have the disadvantage of removing all the past information, even if --retain was specified at some past step. This result is annoying for a lot of users and automated upgrade flows. So, rather than requiring a manual removal of pg_upgrade_output.d/, this redesigns the set of output directories in a more dynamic way, based on a suggestion from Tom Lane and Daniel Gustafsson. pg_upgrade_output.d/ is still the base path, but a second directory level is added, mostly named after an ISO-8601-formatted timestamp (in short human-readable, with milliseconds appended to the name to avoid any conflicts). The logs and dumps are saved within the same subdirectories as previously, as of log/ and dump/, but these are located inside the subdirectory named after the timestamp. The logs of a given run are removed only after a successful run if --retain is not used, and pg_upgrade_output.d/ is kept if there are any logs from a previous run. Note that previously, pg_upgrade would have kept the logs even after a successful --check but that was inconsistent compared to the case without --check when using --retain. The code in charge of the removal of the output directories is now refactored into a single routine. Two TAP tests are added with some --check commands (one failure case and one success case), to look after the issue fixed here. Note that the tests had to be tweaked a bit to fit with the new directory structure so as it can find any logs generated on failure. This is still going to require a change in the buildfarm client for the case where pg_upgrade is tested without the TAP test, though, but I'll tackle that with a separate patch where needed. Reported-by: Tushar Ahuja Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Justin Pryzby Discussion: https://postgr.es/m/77e6ecaa-2785-97aa-f229-4b6e047cbd2b@enterprisedb.com
2022-06-08 03:53:01 +02:00
# Cause a failure at the start of pg_upgrade, this should create the logging
# directory pg_upgrade_output.d but leave it around. Keep --check for an
# early exit.
command_fails(
[
'pg_upgrade', '--no-sync',
'-d', $oldnode->data_dir,
'-D', $newnode->data_dir,
'-b', $oldbindir . '/does/not/exist/',
'-B', $newbindir,
'-s', $newnode->host,
Restructure pg_upgrade output directories for better idempotence 38bfae3 has moved the contents written to files by pg_upgrade under a new directory called pg_upgrade_output.d/ located in the new cluster's data folder, and it used a simple structure made of two subdirectories leading to a fixed structure: log/ and dump/. This design has made weaker pg_upgrade on repeated calls, as we could get failures when creating one or more of those directories, while potentially losing the logs of a previous run (logs are retained automatically on failure, and cleaned up on success unless --retain is specified). So a user would need to clean up pg_upgrade_output.d/ as an extra step for any repeated calls of pg_upgrade. The most common scenario here is --check followed by the actual upgrade, but one could see a failure when specifying an incorrect input argument value. Removing entirely the logs would have the disadvantage of removing all the past information, even if --retain was specified at some past step. This result is annoying for a lot of users and automated upgrade flows. So, rather than requiring a manual removal of pg_upgrade_output.d/, this redesigns the set of output directories in a more dynamic way, based on a suggestion from Tom Lane and Daniel Gustafsson. pg_upgrade_output.d/ is still the base path, but a second directory level is added, mostly named after an ISO-8601-formatted timestamp (in short human-readable, with milliseconds appended to the name to avoid any conflicts). The logs and dumps are saved within the same subdirectories as previously, as of log/ and dump/, but these are located inside the subdirectory named after the timestamp. The logs of a given run are removed only after a successful run if --retain is not used, and pg_upgrade_output.d/ is kept if there are any logs from a previous run. Note that previously, pg_upgrade would have kept the logs even after a successful --check but that was inconsistent compared to the case without --check when using --retain. The code in charge of the removal of the output directories is now refactored into a single routine. Two TAP tests are added with some --check commands (one failure case and one success case), to look after the issue fixed here. Note that the tests had to be tweaked a bit to fit with the new directory structure so as it can find any logs generated on failure. This is still going to require a change in the buildfarm client for the case where pg_upgrade is tested without the TAP test, though, but I'll tackle that with a separate patch where needed. Reported-by: Tushar Ahuja Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Justin Pryzby Discussion: https://postgr.es/m/77e6ecaa-2785-97aa-f229-4b6e047cbd2b@enterprisedb.com
2022-06-08 03:53:01 +02:00
'-p', $oldnode->port,
'-P', $newnode->port,
'--check'
],
'run of pg_upgrade --check for new instance with incorrect binary path');
ok(-d $newnode->data_dir . "/pg_upgrade_output.d",
"pg_upgrade_output.d/ not removed after pg_upgrade failure");
rmtree($newnode->data_dir . "/pg_upgrade_output.d");
# --check command works here, cleans up pg_upgrade_output.d.
command_ok(
[
'pg_upgrade', '--no-sync', '-d', $oldnode->data_dir,
'-D', $newnode->data_dir, '-b', $oldbindir,
'-B', $newbindir, '-s', $newnode->host,
'-p', $oldnode->port, '-P', $newnode->port,
'--check'
Restructure pg_upgrade output directories for better idempotence 38bfae3 has moved the contents written to files by pg_upgrade under a new directory called pg_upgrade_output.d/ located in the new cluster's data folder, and it used a simple structure made of two subdirectories leading to a fixed structure: log/ and dump/. This design has made weaker pg_upgrade on repeated calls, as we could get failures when creating one or more of those directories, while potentially losing the logs of a previous run (logs are retained automatically on failure, and cleaned up on success unless --retain is specified). So a user would need to clean up pg_upgrade_output.d/ as an extra step for any repeated calls of pg_upgrade. The most common scenario here is --check followed by the actual upgrade, but one could see a failure when specifying an incorrect input argument value. Removing entirely the logs would have the disadvantage of removing all the past information, even if --retain was specified at some past step. This result is annoying for a lot of users and automated upgrade flows. So, rather than requiring a manual removal of pg_upgrade_output.d/, this redesigns the set of output directories in a more dynamic way, based on a suggestion from Tom Lane and Daniel Gustafsson. pg_upgrade_output.d/ is still the base path, but a second directory level is added, mostly named after an ISO-8601-formatted timestamp (in short human-readable, with milliseconds appended to the name to avoid any conflicts). The logs and dumps are saved within the same subdirectories as previously, as of log/ and dump/, but these are located inside the subdirectory named after the timestamp. The logs of a given run are removed only after a successful run if --retain is not used, and pg_upgrade_output.d/ is kept if there are any logs from a previous run. Note that previously, pg_upgrade would have kept the logs even after a successful --check but that was inconsistent compared to the case without --check when using --retain. The code in charge of the removal of the output directories is now refactored into a single routine. Two TAP tests are added with some --check commands (one failure case and one success case), to look after the issue fixed here. Note that the tests had to be tweaked a bit to fit with the new directory structure so as it can find any logs generated on failure. This is still going to require a change in the buildfarm client for the case where pg_upgrade is tested without the TAP test, though, but I'll tackle that with a separate patch where needed. Reported-by: Tushar Ahuja Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Justin Pryzby Discussion: https://postgr.es/m/77e6ecaa-2785-97aa-f229-4b6e047cbd2b@enterprisedb.com
2022-06-08 03:53:01 +02:00
],
'run of pg_upgrade --check for new instance');
ok(!-d $newnode->data_dir . "/pg_upgrade_output.d",
"pg_upgrade_output.d/ not removed after pg_upgrade --check success");
# Actual run, pg_upgrade_output.d is removed at the end.
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
command_ok(
[
'pg_upgrade', '--no-sync', '-d', $oldnode->data_dir,
'-D', $newnode->data_dir, '-b', $oldbindir,
'-B', $newbindir, '-s', $newnode->host,
'-p', $oldnode->port, '-P', $newnode->port
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
],
'run of pg_upgrade for new instance');
Restructure pg_upgrade output directories for better idempotence 38bfae3 has moved the contents written to files by pg_upgrade under a new directory called pg_upgrade_output.d/ located in the new cluster's data folder, and it used a simple structure made of two subdirectories leading to a fixed structure: log/ and dump/. This design has made weaker pg_upgrade on repeated calls, as we could get failures when creating one or more of those directories, while potentially losing the logs of a previous run (logs are retained automatically on failure, and cleaned up on success unless --retain is specified). So a user would need to clean up pg_upgrade_output.d/ as an extra step for any repeated calls of pg_upgrade. The most common scenario here is --check followed by the actual upgrade, but one could see a failure when specifying an incorrect input argument value. Removing entirely the logs would have the disadvantage of removing all the past information, even if --retain was specified at some past step. This result is annoying for a lot of users and automated upgrade flows. So, rather than requiring a manual removal of pg_upgrade_output.d/, this redesigns the set of output directories in a more dynamic way, based on a suggestion from Tom Lane and Daniel Gustafsson. pg_upgrade_output.d/ is still the base path, but a second directory level is added, mostly named after an ISO-8601-formatted timestamp (in short human-readable, with milliseconds appended to the name to avoid any conflicts). The logs and dumps are saved within the same subdirectories as previously, as of log/ and dump/, but these are located inside the subdirectory named after the timestamp. The logs of a given run are removed only after a successful run if --retain is not used, and pg_upgrade_output.d/ is kept if there are any logs from a previous run. Note that previously, pg_upgrade would have kept the logs even after a successful --check but that was inconsistent compared to the case without --check when using --retain. The code in charge of the removal of the output directories is now refactored into a single routine. Two TAP tests are added with some --check commands (one failure case and one success case), to look after the issue fixed here. Note that the tests had to be tweaked a bit to fit with the new directory structure so as it can find any logs generated on failure. This is still going to require a change in the buildfarm client for the case where pg_upgrade is tested without the TAP test, though, but I'll tackle that with a separate patch where needed. Reported-by: Tushar Ahuja Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Justin Pryzby Discussion: https://postgr.es/m/77e6ecaa-2785-97aa-f229-4b6e047cbd2b@enterprisedb.com
2022-06-08 03:53:01 +02:00
ok( !-d $newnode->data_dir . "/pg_upgrade_output.d",
"pg_upgrade_output.d/ removed after pg_upgrade success");
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
$newnode->start;
# Check if there are any logs coming from pg_upgrade, that would only be
# retained on failure.
Restructure pg_upgrade output directories for better idempotence 38bfae3 has moved the contents written to files by pg_upgrade under a new directory called pg_upgrade_output.d/ located in the new cluster's data folder, and it used a simple structure made of two subdirectories leading to a fixed structure: log/ and dump/. This design has made weaker pg_upgrade on repeated calls, as we could get failures when creating one or more of those directories, while potentially losing the logs of a previous run (logs are retained automatically on failure, and cleaned up on success unless --retain is specified). So a user would need to clean up pg_upgrade_output.d/ as an extra step for any repeated calls of pg_upgrade. The most common scenario here is --check followed by the actual upgrade, but one could see a failure when specifying an incorrect input argument value. Removing entirely the logs would have the disadvantage of removing all the past information, even if --retain was specified at some past step. This result is annoying for a lot of users and automated upgrade flows. So, rather than requiring a manual removal of pg_upgrade_output.d/, this redesigns the set of output directories in a more dynamic way, based on a suggestion from Tom Lane and Daniel Gustafsson. pg_upgrade_output.d/ is still the base path, but a second directory level is added, mostly named after an ISO-8601-formatted timestamp (in short human-readable, with milliseconds appended to the name to avoid any conflicts). The logs and dumps are saved within the same subdirectories as previously, as of log/ and dump/, but these are located inside the subdirectory named after the timestamp. The logs of a given run are removed only after a successful run if --retain is not used, and pg_upgrade_output.d/ is kept if there are any logs from a previous run. Note that previously, pg_upgrade would have kept the logs even after a successful --check but that was inconsistent compared to the case without --check when using --retain. The code in charge of the removal of the output directories is now refactored into a single routine. Two TAP tests are added with some --check commands (one failure case and one success case), to look after the issue fixed here. Note that the tests had to be tweaked a bit to fit with the new directory structure so as it can find any logs generated on failure. This is still going to require a change in the buildfarm client for the case where pg_upgrade is tested without the TAP test, though, but I'll tackle that with a separate patch where needed. Reported-by: Tushar Ahuja Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Justin Pryzby Discussion: https://postgr.es/m/77e6ecaa-2785-97aa-f229-4b6e047cbd2b@enterprisedb.com
2022-06-08 03:53:01 +02:00
my $log_path = $newnode->data_dir . "/pg_upgrade_output.d";
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
if (-d $log_path)
{
Restructure pg_upgrade output directories for better idempotence 38bfae3 has moved the contents written to files by pg_upgrade under a new directory called pg_upgrade_output.d/ located in the new cluster's data folder, and it used a simple structure made of two subdirectories leading to a fixed structure: log/ and dump/. This design has made weaker pg_upgrade on repeated calls, as we could get failures when creating one or more of those directories, while potentially losing the logs of a previous run (logs are retained automatically on failure, and cleaned up on success unless --retain is specified). So a user would need to clean up pg_upgrade_output.d/ as an extra step for any repeated calls of pg_upgrade. The most common scenario here is --check followed by the actual upgrade, but one could see a failure when specifying an incorrect input argument value. Removing entirely the logs would have the disadvantage of removing all the past information, even if --retain was specified at some past step. This result is annoying for a lot of users and automated upgrade flows. So, rather than requiring a manual removal of pg_upgrade_output.d/, this redesigns the set of output directories in a more dynamic way, based on a suggestion from Tom Lane and Daniel Gustafsson. pg_upgrade_output.d/ is still the base path, but a second directory level is added, mostly named after an ISO-8601-formatted timestamp (in short human-readable, with milliseconds appended to the name to avoid any conflicts). The logs and dumps are saved within the same subdirectories as previously, as of log/ and dump/, but these are located inside the subdirectory named after the timestamp. The logs of a given run are removed only after a successful run if --retain is not used, and pg_upgrade_output.d/ is kept if there are any logs from a previous run. Note that previously, pg_upgrade would have kept the logs even after a successful --check but that was inconsistent compared to the case without --check when using --retain. The code in charge of the removal of the output directories is now refactored into a single routine. Two TAP tests are added with some --check commands (one failure case and one success case), to look after the issue fixed here. Note that the tests had to be tweaked a bit to fit with the new directory structure so as it can find any logs generated on failure. This is still going to require a change in the buildfarm client for the case where pg_upgrade is tested without the TAP test, though, but I'll tackle that with a separate patch where needed. Reported-by: Tushar Ahuja Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Justin Pryzby Discussion: https://postgr.es/m/77e6ecaa-2785-97aa-f229-4b6e047cbd2b@enterprisedb.com
2022-06-08 03:53:01 +02:00
my @log_files;
find(
sub {
push @log_files, $File::Find::name
if $File::Find::name =~ m/.*\.log/;
},
$newnode->data_dir . "/pg_upgrade_output.d");
foreach my $log (@log_files)
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
{
note "=== contents of $log ===\n";
print slurp_file($log);
print "=== EOF ===\n";
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
}
}
# Second dump from the upgraded instance.
@dump_command = (
'pg_dumpall', '--no-sync', '-d', $newnode->connstr('postgres'),
'-f', $dump2_file);
# --extra-float-digits is needed when upgrading from a version older than 11.
push(@dump_command, '--extra-float-digits', '0')
if ($oldnode->pg_version < 12);
$newnode->command_ok(\@dump_command, 'dump after running pg_upgrade');
# No need to apply filters on the dumps if working on the same version
# for the old and new nodes.
my $dump1_filtered = $dump1_file;
my $dump2_filtered = $dump2_file;
if ($oldnode->pg_version != $newnode->pg_version)
{
$dump1_filtered = filter_dump($oldnode, $dump1_file);
$dump2_filtered = filter_dump($newnode, $dump2_file);
}
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
# Compare the two dumps, there should be no differences.
my $compare_res = compare($dump1_filtered, $dump2_filtered);
is($compare_res, 0, 'old and new dumps match after pg_upgrade');
# Provide more context if the dumps do not match.
if ($compare_res != 0)
{
my ($stdout, $stderr) =
run_command([ 'diff', $dump1_filtered, $dump2_filtered ]);
print "=== diff of $dump1_filtered and $dump2_filtered\n";
print "=== stdout ===\n";
print $stdout;
print "=== stderr ===\n";
print $stderr;
print "=== EOF ===\n";
}
Switch the regression tests of pg_upgrade to use TAP tests This simplifies a lot of code in the tests of pg_upgrade without sacrificing its coverage: - Removal of test.sh used for builds with make, that has accumulated over the years tweaks for problems that are solved in a duplicated way by the centralized TAP framework (initialization of the various environment variables PG*, port selection). - Removal of the code in MSVC to test pg_upgrade. This was roughly a duplicate of test.sh adapted for Windows, with an extra footprint of a pg_regress command and all the assumptions behind it. Support for upgrades with older versions is changed, not removed. test.sh was able to set up the regression database on the old instance by launching itself the pg_regress command and a dependency to the source tree of thd old cluster, with tweaks on the command arguments to adapt across the versions used. This created a backward-compatibility dependency with older pg_regress commands, and recent changes like d1029bb have made that much more complicated. Instead, this commit allows tests with older major versions by specifying a path to a SQL dump (taken with pg_dumpall from the old cluster's installation) that will be loaded into the old instance to upgrade instead of running pg_regress, through an optional environment variable called $olddump. This requires a second variable called $oldinstall to point to the base path of the installation of the old cluster. This method is more in line with the buildfarm client that uses a set of static dumps to set up an old instance, so hopefully we will be able to reuse what is introduced in this commit there. The last step of the tests that checks for differences between the two dumps taken still needs to be improved as it can fail, requiring a manual lookup at the dumps. This is not different from the old way of testing where things could fail at the last step. Support for EXTRA_REGRESS_OPTS is kept. vcregress.pl in the MSVC scripts still handles the test of pg_upgrade with its upgradecheck, and bincheck is changed to skip pg_upgrade. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Andres Freund, Rachel Heaton, Tom Lane, Discussion: https://postgr.es/m/YJ8xTmLQkotVLpN5@paquier.xyz
2022-04-01 03:13:50 +02:00
done_testing();