Improve sleep processing of pg_rewind TAP tests

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Improve sleep processing of pg_rewind TAP tests
Date: 2015-04-16 02:41:18
Message-ID: CAB7nPqTfG=g1Cmb4y3KbcihxTrjsk+Y5tyNd4Y7h74bOQoQ5qg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

TAP tests of pg_rewind are using in 2 places hardcoded values to wait
for a given amount of time for some events. In HEAD, those things are:
1) Wait for 1s for standby to catch up.
2) Wait for 2s for promotion of standby.
However after discussion with a colleague we have noticed that those
values may not be enough in slow environments, a value of up to 10s
being sometimes needed after promotion to make tests pass. And
actually the current way of doing is not reliable because it depends
on how the environment is able to handle quickly standby replay and
promotion (I am expecting issues regarding that on Windows btw, and on
small spec machines).

Attached is a patch improving this sleep logic and doing the following things:
1) To ensure that standby has caught up, check replay position on the
standby and compare it with the current WAL position of master.
2) To ensure that promotion is effective, use pg_is_in_recovery() and
continue processing until we are sure that the standby is out of
recovery.
In each case the patch attached makes a maximum of 30 attempts, each
attempt waiting 1s before processing, so we let a margin of up to 30s
for environments to handle replay and promotion properly.

Note that this patch adds a small routine called command_result in
TestLib.pm, able to return stdout, stderr and the exit code. That's
really handy, and I am planning to use something like that as well in
the replication test suite.
Regards,
--
Michael

Attachment Content-Type Size
20150416_pg_rewind_robust_sleep.patch text/x-diff 3.2 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-04-16 02:44:48 Re: PATCH: default_index_tablespace
Previous Message Bruce Momjian 2015-04-16 02:31:46 Re: PATCH: default_index_tablespace