Re: Recovery test failure for recovery_min_apply_delay on hamster
От | Michael Paquier |
---|---|
Тема | Re: Recovery test failure for recovery_min_apply_delay on hamster |
Дата | |
Msg-id | CAB7nPqQCVU=_VGTJBH03ccE9topatyZi6YSJFtrG4UPUP=b2yw@mail.gmail.com обсуждение исходный текст |
Ответ на | Recovery test failure for recovery_min_apply_delay on hamster (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Recovery test failure for recovery_min_apply_delay on
hamster
|
Список | pgsql-hackers |
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. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: