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.
--
Michael
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'
));
$node_standby->start;
-# 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();
$node_master->safe_psql('postgres',
"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:
http://www.postgresql.org/mailpref/pgsql-hackers
