Fix assorted problems in recovery tests
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 3 Aug 2016 17:21:23 +0000 (13:21 -0400)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 3 Aug 2016 17:21:23 +0000 (13:21 -0400)
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 2a0f89cd717 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

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

index 82bad85717e3d0723473ab9071bfce410e166362..fd71095f06ad37729b62a27dd84a0df973e9adbf 100644 (file)
@@ -38,11 +38,11 @@ $node_master->safe_psql('postgres',
 my $applname_1 = $node_standby_1->name;
 my $applname_2 = $node_standby_2->name;
 my $caughtup_query =
-"SELECT pg_current_xlog_location() <= write_location FROM pg_stat_replication WHERE application_name = '$applname_1';";
+"SELECT pg_current_xlog_location() <= replay_location FROM pg_stat_replication WHERE application_name = '$applname_1';";
 $node_master->poll_query_until('postgres', $caughtup_query)
   or die "Timed out while waiting for standby 1 to catch up";
 $caughtup_query =
-"SELECT pg_last_xlog_replay_location() <= write_location FROM pg_stat_replication WHERE application_name = '$applname_2';";
+"SELECT pg_last_xlog_replay_location() <= replay_location FROM pg_stat_replication WHERE application_name = '$applname_2';";
 $node_standby_1->poll_query_until('postgres', $caughtup_query)
   or die "Timed out while waiting for standby 2 to catch up";
 
index b69bbadb3c8a4d2358b0fed30a193ed761a84228..82371503cccc792357f8fffb508cac9eb1e08f25 100644 (file)
@@ -66,17 +66,16 @@ $node_master->backup('my_backup');
 # target TXID.
 $node_master->safe_psql('postgres',
        "INSERT INTO tab_int VALUES (generate_series(1001,2000))");
-my $recovery_txid =
-  $node_master->safe_psql('postgres', "SELECT txid_current()");
-my $lsn2 =
-  $node_master->safe_psql('postgres', "SELECT pg_current_xlog_location();");
+my $ret =
+  $node_master->safe_psql('postgres', "SELECT pg_current_xlog_location(), txid_current();");
+my ($lsn2, $recovery_txid) = split /\|/, $ret;
 
 # More data, with recovery target timestamp
 $node_master->safe_psql('postgres',
        "INSERT INTO tab_int VALUES (generate_series(2001,3000))");
-my $recovery_time = $node_master->safe_psql('postgres', "SELECT now()");
-my $lsn3 =
-  $node_master->safe_psql('postgres', "SELECT pg_current_xlog_location();");
+$ret =
+  $node_master->safe_psql('postgres', "SELECT pg_current_xlog_location(), now();");
+my ($lsn3, $recovery_time) = split /\|/, $ret;
 
 # Even more data, this time with a recovery target name
 $node_master->safe_psql('postgres',