2021-05-07 16:56:14 +02:00
|
|
|
|
2022-01-08 01:04:57 +01:00
|
|
|
# Copyright (c) 2021-2022, PostgreSQL Global Development Group
|
2021-05-07 16:56:14 +02:00
|
|
|
|
2016-08-04 20:44:23 +02:00
|
|
|
use strict;
|
|
|
|
use warnings;
|
|
|
|
|
2021-10-24 16:28:19 +02:00
|
|
|
use PostgreSQL::Test::Cluster;
|
|
|
|
use PostgreSQL::Test::Utils;
|
2019-03-04 23:11:18 +01:00
|
|
|
use Test::More;
|
|
|
|
|
2021-10-24 16:28:19 +02:00
|
|
|
if ($PostgreSQL::Test::Utils::is_msys2)
|
2019-03-04 23:11:18 +01:00
|
|
|
{
|
|
|
|
plan skip_all => 'High bit name tests fail on Msys2';
|
|
|
|
}
|
2016-08-04 20:44:23 +02:00
|
|
|
|
2019-05-12 19:33:05 +02:00
|
|
|
# We're going to use byte sequences that aren't valid UTF-8 strings. Use
|
|
|
|
# LATIN1, which accepts any byte and has a conversion from each byte to UTF-8.
|
2017-01-31 18:42:16 +01:00
|
|
|
$ENV{LC_ALL} = 'C';
|
2016-08-04 20:44:23 +02:00
|
|
|
$ENV{PGCLIENTENCODING} = 'LATIN1';
|
|
|
|
|
|
|
|
# Create database and user names covering the range of LATIN1
|
|
|
|
# characters, for use in a connection string by pg_dumpall. Skip ','
|
|
|
|
# because of pg_regress --create-role, skip [\n\r] because pg_dumpall
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
# does not allow them. We also skip many ASCII letters, to keep the
|
|
|
|
# total number of tested characters to what will fit in four names.
|
|
|
|
# The odds of finding something interesting by testing all ASCII letters
|
|
|
|
# seem too small to justify the cycles of testing a fifth name.
|
2017-01-31 18:42:16 +01:00
|
|
|
my $dbname1 =
|
2020-07-16 20:48:37 +02:00
|
|
|
'regression'
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
. generate_ascii_string(1, 9)
|
2017-01-31 18:42:16 +01:00
|
|
|
. generate_ascii_string(11, 12)
|
|
|
|
. generate_ascii_string(14, 33)
|
2021-10-24 16:28:19 +02:00
|
|
|
. (
|
|
|
|
$PostgreSQL::Test::Utils::windows_os
|
|
|
|
? ''
|
|
|
|
: '"x"') # IPC::Run mishandles '"' on Windows
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
. generate_ascii_string(35, 43) # skip ','
|
|
|
|
. generate_ascii_string(45, 54);
|
|
|
|
my $dbname2 = 'regression' . generate_ascii_string(55, 65) # skip 'B'-'W'
|
|
|
|
. generate_ascii_string(88, 99) # skip 'd'-'w'
|
|
|
|
. generate_ascii_string(120, 149);
|
|
|
|
my $dbname3 = 'regression' . generate_ascii_string(150, 202);
|
|
|
|
my $dbname4 = 'regression' . generate_ascii_string(203, 255);
|
|
|
|
|
|
|
|
(my $username1 = $dbname1) =~ s/^regression/regress_/;
|
|
|
|
(my $username2 = $dbname2) =~ s/^regression/regress_/;
|
|
|
|
(my $username3 = $dbname3) =~ s/^regression/regress_/;
|
|
|
|
(my $username4 = $dbname4) =~ s/^regression/regress_/;
|
|
|
|
|
|
|
|
my $src_bootstrap_super = 'regress_postgres';
|
|
|
|
my $dst_bootstrap_super = 'boot';
|
2016-08-04 20:44:23 +02:00
|
|
|
|
2021-10-24 16:28:19 +02:00
|
|
|
my $node = PostgreSQL::Test::Cluster->new('main');
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
$node->init(extra =>
|
|
|
|
[ '-U', $src_bootstrap_super, '--locale=C', '--encoding=LATIN1' ]);
|
2017-01-31 18:42:16 +01:00
|
|
|
|
2016-08-04 20:44:23 +02:00
|
|
|
# prep pg_hba.conf and pg_ident.conf
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->run_log(
|
2018-05-09 16:14:46 +02:00
|
|
|
[
|
2019-06-30 19:34:45 +02:00
|
|
|
$ENV{PG_REGRESS}, '--config-auth',
|
|
|
|
$node->data_dir, '--user',
|
|
|
|
$src_bootstrap_super, '--create-role',
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
"$username1,$username2,$username3,$username4"
|
2018-05-09 16:14:46 +02:00
|
|
|
]);
|
2016-08-04 20:44:23 +02:00
|
|
|
$node->start;
|
|
|
|
|
|
|
|
my $backupdir = $node->backup_dir;
|
2017-01-31 18:42:16 +01:00
|
|
|
my $discard = "$backupdir/discard.sql";
|
|
|
|
my $plain = "$backupdir/plain.sql";
|
|
|
|
my $dirfmt = "$backupdir/dirfmt";
|
2016-08-04 20:44:23 +02:00
|
|
|
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
$node->run_log([ 'createdb', '-U', $src_bootstrap_super, $dbname1 ]);
|
|
|
|
$node->run_log(
|
|
|
|
[ 'createuser', '-U', $src_bootstrap_super, '-s', $username1 ]);
|
|
|
|
$node->run_log([ 'createdb', '-U', $src_bootstrap_super, $dbname2 ]);
|
|
|
|
$node->run_log(
|
|
|
|
[ 'createuser', '-U', $src_bootstrap_super, '-s', $username2 ]);
|
|
|
|
$node->run_log([ 'createdb', '-U', $src_bootstrap_super, $dbname3 ]);
|
|
|
|
$node->run_log(
|
|
|
|
[ 'createuser', '-U', $src_bootstrap_super, '-s', $username3 ]);
|
|
|
|
$node->run_log([ 'createdb', '-U', $src_bootstrap_super, $dbname4 ]);
|
|
|
|
$node->run_log(
|
|
|
|
[ 'createuser', '-U', $src_bootstrap_super, '-s', $username4 ]);
|
2016-08-04 20:44:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
# For these tests, pg_dumpall -r is used because it produces a short
|
|
|
|
# dump.
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->command_ok(
|
2018-05-09 16:14:46 +02:00
|
|
|
[
|
|
|
|
'pg_dumpall', '-r', '-f', $discard, '--dbname',
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->connstr($dbname1),
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
'-U', $username4
|
2018-05-09 16:14:46 +02:00
|
|
|
],
|
2017-01-31 18:42:16 +01:00
|
|
|
'pg_dumpall with long ASCII name 1');
|
|
|
|
$node->command_ok(
|
2018-05-09 16:14:46 +02:00
|
|
|
[
|
|
|
|
'pg_dumpall', '--no-sync', '-r', '-f', $discard, '--dbname',
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->connstr($dbname2),
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
'-U', $username3
|
2018-05-09 16:14:46 +02:00
|
|
|
],
|
2017-01-31 18:42:16 +01:00
|
|
|
'pg_dumpall with long ASCII name 2');
|
|
|
|
$node->command_ok(
|
2018-05-09 16:14:46 +02:00
|
|
|
[
|
|
|
|
'pg_dumpall', '--no-sync', '-r', '-f', $discard, '--dbname',
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->connstr($dbname3),
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
'-U', $username2
|
2018-05-09 16:14:46 +02:00
|
|
|
],
|
2017-01-31 18:42:16 +01:00
|
|
|
'pg_dumpall with long ASCII name 3');
|
|
|
|
$node->command_ok(
|
2018-05-09 16:14:46 +02:00
|
|
|
[
|
|
|
|
'pg_dumpall', '--no-sync', '-r', '-f', $discard, '--dbname',
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->connstr($dbname4),
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
'-U', $username1
|
2018-05-09 16:14:46 +02:00
|
|
|
],
|
2017-01-31 18:42:16 +01:00
|
|
|
'pg_dumpall with long ASCII name 4');
|
|
|
|
$node->command_ok(
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
[
|
|
|
|
'pg_dumpall', '-U',
|
|
|
|
$src_bootstrap_super, '--no-sync',
|
|
|
|
'-r', '-l',
|
|
|
|
'dbname=template1'
|
|
|
|
],
|
2017-01-31 18:42:16 +01:00
|
|
|
'pg_dumpall -l accepts connection string');
|
|
|
|
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
$node->run_log([ 'createdb', '-U', $src_bootstrap_super, "foo\n\rbar" ]);
|
2017-01-31 18:42:16 +01:00
|
|
|
|
2016-08-04 20:44:23 +02:00
|
|
|
# not sufficient to use -r here
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->command_fails(
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
[ 'pg_dumpall', '-U', $src_bootstrap_super, '--no-sync', '-f', $discard ],
|
2017-01-31 18:42:16 +01:00
|
|
|
'pg_dumpall with \n\r in database name');
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
$node->run_log([ 'dropdb', '-U', $src_bootstrap_super, "foo\n\rbar" ]);
|
2016-08-04 20:44:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
# make a table, so the parallel worker has something to dump
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
$node->safe_psql(
|
|
|
|
$dbname1,
|
|
|
|
'CREATE TABLE t0()',
|
|
|
|
extra_params => [ '-U', $src_bootstrap_super ]);
|
2017-01-31 18:42:16 +01:00
|
|
|
|
2016-08-04 20:44:23 +02:00
|
|
|
# XXX no printed message when this fails, just SIGPIPE termination
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->command_ok(
|
2018-05-09 16:14:46 +02:00
|
|
|
[
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
'pg_dump', '-Fd', '--no-sync', '-j2', '-f', $dirfmt, '-U', $username1,
|
2018-05-09 16:14:46 +02:00
|
|
|
$node->connstr($dbname1)
|
|
|
|
],
|
2017-01-31 18:42:16 +01:00
|
|
|
'parallel dump');
|
2016-08-04 20:44:23 +02:00
|
|
|
|
|
|
|
# recreate $dbname1 for restore test
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
$node->run_log([ 'dropdb', '-U', $src_bootstrap_super, $dbname1 ]);
|
|
|
|
$node->run_log([ 'createdb', '-U', $src_bootstrap_super, $dbname1 ]);
|
2016-08-04 20:44:23 +02:00
|
|
|
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->command_ok(
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
[
|
|
|
|
'pg_restore', '-v', '-d', 'template1',
|
|
|
|
'-j2', '-U', $username1, $dirfmt
|
|
|
|
],
|
2017-01-31 18:42:16 +01:00
|
|
|
'parallel restore');
|
2016-08-04 20:44:23 +02:00
|
|
|
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
$node->run_log([ 'dropdb', '-U', $src_bootstrap_super, $dbname1 ]);
|
2016-08-04 20:44:23 +02:00
|
|
|
|
2017-01-31 18:42:16 +01:00
|
|
|
$node->command_ok(
|
2018-05-09 16:14:46 +02:00
|
|
|
[
|
|
|
|
'pg_restore', '-C', '-v', '-d',
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
'template1', '-j2', '-U', $username1,
|
2018-05-09 16:14:46 +02:00
|
|
|
$dirfmt
|
|
|
|
],
|
2017-01-31 18:42:16 +01:00
|
|
|
'parallel restore with create');
|
2016-08-04 20:44:23 +02:00
|
|
|
|
|
|
|
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
$node->command_ok(
|
|
|
|
[ 'pg_dumpall', '--no-sync', '-f', $plain, '-U', $username1 ],
|
2017-01-31 18:42:16 +01:00
|
|
|
'take full dump');
|
2016-08-04 20:44:23 +02:00
|
|
|
system_log('cat', $plain);
|
2017-01-31 18:42:16 +01:00
|
|
|
my ($stderr, $result);
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
my $restore_super = qq{regress_a'b\\c=d\\ne"f};
|
2019-07-04 04:33:42 +02:00
|
|
|
$restore_super =~ s/"//g
|
2021-10-24 16:28:19 +02:00
|
|
|
if
|
|
|
|
$PostgreSQL::Test::Utils::windows_os; # IPC::Run mishandles '"' on Windows
|
2016-08-04 20:44:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
# Restore full dump through psql using environment variables for
|
|
|
|
# dbname/user connection parameters
|
|
|
|
|
2021-10-24 16:28:19 +02:00
|
|
|
my $envar_node = PostgreSQL::Test::Cluster->new('destination_envar');
|
2019-07-04 04:33:42 +02:00
|
|
|
$envar_node->init(
|
|
|
|
extra =>
|
|
|
|
[ '-U', $dst_bootstrap_super, '--locale=C', '--encoding=LATIN1' ],
|
|
|
|
auth_extra =>
|
|
|
|
[ '--user', $dst_bootstrap_super, '--create-role', $restore_super ]);
|
2016-08-04 20:44:23 +02:00
|
|
|
$envar_node->start;
|
|
|
|
|
|
|
|
# make superuser for restore
|
2017-01-31 18:42:16 +01:00
|
|
|
$envar_node->run_log(
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
[ 'createuser', '-U', $dst_bootstrap_super, '-s', $restore_super ]);
|
2016-08-04 20:44:23 +02:00
|
|
|
|
|
|
|
{
|
|
|
|
local $ENV{PGPORT} = $envar_node->port;
|
|
|
|
local $ENV{PGUSER} = $restore_super;
|
2017-01-31 18:42:16 +01:00
|
|
|
$result = run_log([ 'psql', '-X', '-f', $plain ], '2>', \$stderr);
|
2016-08-04 20:44:23 +02:00
|
|
|
}
|
2017-01-31 18:42:16 +01:00
|
|
|
ok($result,
|
|
|
|
'restore full dump using environment variables for connection parameters'
|
|
|
|
);
|
2016-08-04 20:44:23 +02:00
|
|
|
is($stderr, '', 'no dump errors');
|
|
|
|
|
|
|
|
|
|
|
|
# Restore full dump through psql using command-line options for
|
|
|
|
# dbname/user connection parameters. "\connect dbname=" forgets
|
|
|
|
# user/port from command line.
|
|
|
|
|
2021-10-24 16:28:19 +02:00
|
|
|
my $cmdline_node = PostgreSQL::Test::Cluster->new('destination_cmdline');
|
2019-07-04 04:33:42 +02:00
|
|
|
$cmdline_node->init(
|
|
|
|
extra =>
|
|
|
|
[ '-U', $dst_bootstrap_super, '--locale=C', '--encoding=LATIN1' ],
|
|
|
|
auth_extra =>
|
|
|
|
[ '--user', $dst_bootstrap_super, '--create-role', $restore_super ]);
|
2016-08-04 20:44:23 +02:00
|
|
|
$cmdline_node->start;
|
2017-01-31 18:42:16 +01:00
|
|
|
$cmdline_node->run_log(
|
Fix regression tests to use only global names beginning with "regress_".
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
2019-06-29 17:09:03 +02:00
|
|
|
[ 'createuser', '-U', $dst_bootstrap_super, '-s', $restore_super ]);
|
2016-08-04 20:44:23 +02:00
|
|
|
{
|
2017-01-31 18:42:16 +01:00
|
|
|
$result = run_log(
|
2018-05-09 16:14:46 +02:00
|
|
|
[
|
|
|
|
'psql', '-p', $cmdline_node->port, '-U',
|
|
|
|
$restore_super, '-X', '-f', $plain
|
|
|
|
],
|
2017-01-31 18:42:16 +01:00
|
|
|
'2>',
|
|
|
|
\$stderr);
|
2016-08-04 20:44:23 +02:00
|
|
|
}
|
2017-01-31 18:42:16 +01:00
|
|
|
ok($result,
|
|
|
|
'restore full dump with command-line options for connection parameters');
|
2016-08-04 20:44:23 +02:00
|
|
|
is($stderr, '', 'no dump errors');
|
2022-02-11 20:54:44 +01:00
|
|
|
|
|
|
|
done_testing();
|