On Sun, Mar 13, 2016 at 10:18:46PM +0100, Michael Paquier wrote:
> On Wed, Mar 9, 2016 at 9:05 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > On Wed, Mar 9, 2016 at 12:29 PM, Alvaro Herrera
> > <alvherre@2ndquadrant.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.
>
> Actually, the attached is better. This one relies on time() to perform
> the delay checks, and takes care of things even for slow machines.
[This is a generic notification.]
The above-described topic is currently a PostgreSQL 9.6 open item. Alvaro,
since you committed the patch believed to have created it, you own this open
item. If that responsibility lies elsewhere, please let us know whose
responsibility it is to fix this. Since new open items may be discovered at
any time and I want to plan to have them all fixed well in advance of the ship
date, I will appreciate your efforts toward speedy resolution. Please
present, within 72 hours, a plan to fix the defect within seven days of this
message. Thanks.