Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit b26f7fa

Browse files
committed
Fix assorted problems in recovery tests
In test 001_stream_rep we're using pg_stat_replication.write_location to determine catch-up status, but we care about xlog having been applied not just received, so change that to apply_location. In test 003_recovery_targets, we query the database for a recovery target specification and later for the xlog position supposedly corresponding to that recovery specification. If for whatever reason more WAL is written between the two queries, the recovery specification is earlier than the xlog position used by the query in the test harness, so we wait forever, leading to test failures. Deal with this by using a single query to extract both items. In 2a0f89c we tried to deal with it by giving them more tests to run, but in hindsight that was obviously doomed to failure (no revert of that, though). Per hamster buildfarm failures. Author: Michaël Paquier
1 parent 69bdfc4 commit b26f7fa

File tree

2 files changed

+8
-9
lines changed

2 files changed

+8
-9
lines changed

src/test/recovery/t/001_stream_rep.pl

+2-2
Original file line numberDiff line numberDiff line change
@@ -38,11 +38,11 @@
3838
my $applname_1 = $node_standby_1->name;
3939
my $applname_2 = $node_standby_2->name;
4040
my $caughtup_query =
41-
"SELECT pg_current_xlog_location() <= write_location FROM pg_stat_replication WHERE application_name = '$applname_1';";
41+
"SELECT pg_current_xlog_location() <= replay_location FROM pg_stat_replication WHERE application_name = '$applname_1';";
4242
$node_master->poll_query_until('postgres', $caughtup_query)
4343
or die "Timed out while waiting for standby 1 to catch up";
4444
$caughtup_query =
45-
"SELECT pg_last_xlog_replay_location() <= write_location FROM pg_stat_replication WHERE application_name = '$applname_2';";
45+
"SELECT pg_last_xlog_replay_location() <= replay_location FROM pg_stat_replication WHERE application_name = '$applname_2';";
4646
$node_standby_1->poll_query_until('postgres', $caughtup_query)
4747
or die "Timed out while waiting for standby 2 to catch up";
4848

src/test/recovery/t/003_recovery_targets.pl

+6-7
Original file line numberDiff line numberDiff line change
@@ -66,17 +66,16 @@ sub test_recovery_standby
6666
# target TXID.
6767
$node_master->safe_psql('postgres',
6868
"INSERT INTO tab_int VALUES (generate_series(1001,2000))");
69-
my $recovery_txid =
70-
$node_master->safe_psql('postgres', "SELECT txid_current()");
71-
my $lsn2 =
72-
$node_master->safe_psql('postgres', "SELECT pg_current_xlog_location();");
69+
my $ret =
70+
$node_master->safe_psql('postgres', "SELECT pg_current_xlog_location(), txid_current();");
71+
my ($lsn2, $recovery_txid) = split /\|/, $ret;
7372
7473
# More data, with recovery target timestamp
7574
$node_master->safe_psql('postgres',
7675
"INSERT INTO tab_int VALUES (generate_series(2001,3000))");
77-
my $recovery_time = $node_master->safe_psql('postgres', "SELECT now()");
78-
my $lsn3 =
79-
$node_master->safe_psql('postgres', "SELECT pg_current_xlog_location();");
76+
$ret =
77+
$node_master->safe_psql('postgres', "SELECT pg_current_xlog_location(), now();");
78+
my ($lsn3, $recovery_time) = split /\|/, $ret;
8079

8180
# Even more data, this time with a recovery target name
8281
$node_master->safe_psql('postgres',

0 commit comments

Comments
 (0)