Michael Paquier wrote:
> On Wed, Mar 2, 2016 at 2:04 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > Here are a couple of ways to address this problem:
> > 1) Remove the check before applying the delay
> > 2) Increase recovery_min_apply_delay to a time that will allow even
> > slow machines to see a difference. By experience with the other tests
> > 30s would be enough. The sleep time needs to be increased as well,
> > making the time taken for the test to run longer
> > 3) Remove all together 005, because doing either 1) or 2) reduces the
> > value of the test.
> > I'd like 1) personally, I still see value in this test.
>
> So, as doing 1) would be actually equivalent to simply having a master
> and checking that its standby replicates correctly, I have been
> looking at 2) to see to how long the delay has to be set to make the
> test failure-proof. After doing some measurements with hamster, 10s
> and 15s have proved to not be enough unfortunately, 20s has not failed
> in 10 attempts though. Attached is a patch to bump it to 20s, though I
> would not complain if the test is actually removed to accelerate the
> runs of this test suite.
Is there anything we can do to short-circuit the wait in the case that
replication happens promptly? A one-minute wait would be acceptable we
terminate it early by checking every second.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services