On Wed, Mar 9, 2016 at 12:29 PM, Alvaro Herrera
> Michael Paquier wrote:
>> After sleeping (best debugger ever) on that, actually a way popped up
>> in my mind, and I propose the attached, which refactors a bit 005 and
>> checks that the LSN position of master has been applied on standby
>> after at least the delay wanted. A maximum delay of 90s is authorized,
>> like poll_query_until.
> Hmm, okay, that's great. A question: what happens if the test itself is
> slow and the servers are fast, and the test doesn't manage to run two
> iterations before the two seconds have elapsed? This may happen on
> overloaded or slow servers, if you're unlucky.
Yes, a failure would happen. The same thought occurred to me during a
long flight. And this is why the previous patch was full of meh.
> I don't have any ideas on ensuring that we don't apply earlier than the
> given period at the moment.
Attached is one, which is based on timestamp values queried from the
standby server. We could use as well perl's localtime call to
calculate the time delay.
diff --git a/src/test/recovery/t/005_replay_delay.pl b/src/test/recovery/t/005_replay_delay.pl
index 986851b..74d3c91 100644
@@ -3,7 +3,7 @@ use strict;
-use Test::More tests => 2;
+use Test::More tests => 1;
# Initialize master node
my $node_master = get_new_node('master');
@@ -32,18 +32,40 @@ $node_standby->start;
# depending on the delay of 2s applied above.
"INSERT INTO tab_int VALUES (generate_series(11,20))");
-# Here we should have only 10 rows
-my $result = $node_standby->safe_psql('postgres', "SELECT count(*) FROM tab_int");
-is($result, qq(10), 'check content with delay of 1s');
-# Now wait for replay to complete on standby
+# Now wait for replay to complete on standby. We check if the current
+# LSN of master has been applied after at least 2s. This uses timestamps
+# to be sure that at least the delay time has passed, as on slow machines
+# it may take more than the delay time to reach the first attempt loop.
my $until_lsn =
$node_master->safe_psql('postgres', "SELECT pg_current_xlog_location();");
-my $caughtup_query =
- "SELECT '$until_lsn'::pg_lsn <= pg_last_xlog_replay_location()";
- or die "Timed out while waiting for standby to catch up";
-$result = $node_standby->safe_psql('postgres', "SELECT count(*) FROM tab_int");
-is($result, qq(20), 'check content with delay of 2s');
+my $standby_insert_time =
+ $node_standby->safe_psql('postgres', "SELECT now();");
+my $max_attempts = 90;
+my $attempts = 0;
+my $delay_status = 0;
+while ($attempts < $max_attempts)
+ my $replay_status =
+ "SELECT (pg_last_xlog_replay_location() - '$until_lsn'::pg_lsn) >= 0;");
+ my $delay_applied =
+ "SELECT now() - '$standby_insert_time'::timestamptz >= interval '2s';");
+ $delay_status = $delay_applied eq 't' ? 1 : 0;
+ # Leave now if standby has replayed at least up to the point of
+ # master. It's time to see if data has been applied after the wanted
+ # delay.
+ last if $replay_status eq 't';
+ sleep 1;
+die "Maximum number of attempts reached" if $attempts >= $max_attempts;
+# This test is valid only if LSN has been applied with at least
+# the minimum apply delay expected.
+ok($delay_status, 'Check if WAL is applied on standby after delay of 2s');
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: