Re: Recovery test failure for recovery_min_apply_delay on hamster

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: Recovery test failure for recovery_min_apply_delay on hamster
Date: 2016-03-09 20:05:40
Message-ID: CAB7nPqTQXxrr79U7B7d2hfxbpVqdaSM3MjUV4C=3G1a58S2-aw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 9, 2016 at 12:29 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Michael Paquier wrote:
>> After sleeping (best debugger ever) on that, actually a way popped up
>> in my mind, and I propose the attached, which refactors a bit 005 and
>> checks that the LSN position of master has been applied on standby
>> after at least the delay wanted. A maximum delay of 90s is authorized,
>> like poll_query_until.
>
> Hmm, okay, that's great. A question: what happens if the test itself is
> slow and the servers are fast, and the test doesn't manage to run two
> iterations before the two seconds have elapsed? This may happen on
> overloaded or slow servers, if you're unlucky.

Yes, a failure would happen. The same thought occurred to me during a
long flight. And this is why the previous patch was full of meh.

> I don't have any ideas on ensuring that we don't apply earlier than the
> given period at the moment.

Attached is one, which is based on timestamp values queried from the
standby server. We could use as well perl's localtime call to
calculate the time delay.
--
Michael

Attachment Content-Type Size
fix-recovery-delay-v3.patch text/x-patch 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-03-09 20:08:24 Re: pg_ctl promote wait
Previous Message Alexander Korotkov 2016-03-09 19:33:46 Re: WIP: Upper planner pathification