Michael Paquier wrote: > On Wed, Mar 2, 2016 at 2:04 PM, Michael Paquier > <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
