On Thu, Apr 14, 2016 at 5:17 PM, Masahiko Sawada <[email protected]> wrote:
> On Thu, Apr 14, 2016 at 1:22 PM, Michael Paquier
> <[email protected]> wrote:
>> Yes. I'd prefer avoid a hardcoded sleep and have something that relies
>> on lookups of pg_stat_replication though, because there is no way to
>> be sure that a sleep will ever be stable on heavily loaded machines,
>> like the machines I am specialized in maintaining :)
>> It kills a bit the purpose on having checks on pg_stat_replication as
>> the validation tests are based on that, still I think that we had
>> better base those checks on a loop that has a timeout, something like
>> that in a subroutine:
>> What do you think?
>
> Look good to me. +1.
And so here we go...
--
Michael
diff --git a/src/test/recovery/t/007_sync_rep.pl b/src/test/recovery/t/007_sync_rep.pl
index c257b6e..908fe49 100644
--- a/src/test/recovery/t/007_sync_rep.pl
+++ b/src/test/recovery/t/007_sync_rep.pl
@@ -22,8 +22,28 @@ sub test_sync_state
$self->reload;
}
- my $result = $self->safe_psql('postgres', $check_sql);
- is($result, $expected, $msg);
+ my $timeout_max = 30;
+ my $timeout = 0;
+ my $test_passed = 0;
+
+ # A reload may take some time to take effect on busy machines,
+ # hence use a loop with a timeout to give some room for the test
+ # to pass.
+ while ($timeout < $timeout_max)
+ {
+ my $result = $self->safe_psql('postgres', $check_sql);
+
+ if ($result eq $expected)
+ {
+ $test_passed = 1;
+ last;
+ }
+
+ $timeout++;
+ sleep 1;
+ }
+
+ ok($test_passed, $msg);
}
# Initialize master node
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
