Re: Improve sleep processing of pg_rewind TAP tests

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve sleep processing of pg_rewind TAP tests
Date: 2015-04-20 02:21:57
Message-ID: CAB7nPqQGCEXtVSgjhsbnXXC93Eetycvok4gdOs+kDdsrmD-vHQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-04-20 03:07:18 Re: alternative compression algorithms?
Previous Message Jeff Janes 2015-04-20 02:09:11 optimizing vacuum truncation scans