On Wed, Mar 9, 2016 at 9:05 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Wed, Mar 9, 2016 at 12:29 PM, Alvaro Herrera
> <alvhe...@2ndquadrant.com> wrote:
>> 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.

Actually, the attached is better. This one relies on time() to perform
the delay checks, and takes care of things even for slow machines.
diff --git a/src/test/recovery/t/005_replay_delay.pl b/src/test/recovery/t/005_replay_delay.pl
index 986851b..78bcff6 100644
--- a/src/test/recovery/t/005_replay_delay.pl
+++ b/src/test/recovery/t/005_replay_delay.pl
@@ -3,7 +3,7 @@ use strict;
 use warnings;
 use PostgresNode;
 use TestLib;
-use Test::More tests => 2;
+use Test::More tests => 1;
 # Initialize master node
 my $node_master = get_new_node('master');
@@ -28,22 +28,41 @@ recovery_min_apply_delay = '2s'
-# Make new content on master and check its presence in standby
-# depending on the delay of 2s applied above.
+# Make new content on master and check its presence in standby depending
+# on the delay of 2s applied above. Before doing the insertion, get the
+# current timestamp that will be used as a comparison base. Even on slow
+# machines, this allows to have a predictable behavior when comparing the
+# delay between data insertion moment on master and replay time on standby.
+my $standby_insert_time = time();
 	"INSERT INTO tab_int VALUES (generate_series(11,20))");
-sleep 1;
-# 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 leave once check the
+# previously saved LSN of master has been applied, and then compare the
+# insertion timestamp with the current one.
 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()";
-$node_standby->poll_query_until('postgres', $caughtup_query)
-  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 $max_attempts = 90;
+my $attempts     = 0;
+while ($attempts < $max_attempts)
+	my $replay_status =
+	  $node_standby->safe_psql('postgres',
+		"SELECT (pg_last_xlog_replay_location() - '$until_lsn'::pg_lsn) >= 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;
+	$attempts++;
+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(time() - $standby_insert_time >= 2,
+   'Check if WAL is applied on standby after delay of 2s');
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to