Re: Improve sleep processing of pg_rewind TAP tests - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Improve sleep processing of pg_rewind TAP tests
Date
Msg-id CAB7nPqQGCEXtVSgjhsbnXXC93Eetycvok4gdOs+kDdsrmD-vHQ@mail.gmail.com
Whole thread Raw
In response to Re: Improve sleep processing of pg_rewind TAP tests  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Improve sleep processing of pg_rewind TAP tests
List pgsql-hackers
On Thu, Apr 16, 2015 at 1:00 PM, Michael Paquier wrote:
> Visibly that's not the case for this test case, the timing issues that
> we saw happened not because of the standby not catching up, but
> because of the promotion not taking effect in a timely fashion. And
> that's as well something I saw on my OSX box some days ago as well,
> explaining why the sleep time has been increased from 1 to 2 in
> 53ba1077. This patch just takes it the careful way. In perl, system
> waits for the process of pg_ctl to exit before moving on, perhaps the
> problem is that pg_ctl thinks that promotion is done, but the node is
> not quite ready, explaining why the test fails.

I have just made a run of the TAP tests of pg_rewind on my raspberry
PI 1 (hamster), where the tests are very slow, and I noticed that it
takes up to 10s to get confirmation from standby that it has caught up
with the changes from master, and 5s to get confirmation that standby
has been promoted. So the tests in HEAD would be broken without this
patch, and 30s gives visibly enough room.

Note as well that I would like to enable the TAP tests on this
buildfarm machine btw. It may be good to get some input where things
are really slow even for other tests.
Regards,
-- 
Michael



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: optimizing vacuum truncation scans
Next
From: Andres Freund
Date:
Subject: Re: alternative compression algorithms?