From: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Time-Delayed Standbys |
Date: | 2013-12-13 13:52:52 |
Message-ID: | CAFcNs+qBaBnaRJtc_1jUvDVg9DAUYN846hL+g7eWyzy_uqWkUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 13, 2013 at 11:44 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On 13 December 2013 13:22, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > On 2013-12-13 13:09:13 +0000, Simon Riggs wrote:
> >> On 13 December 2013 11:58, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:
> >> > On 2013-12-13 11:56:47 +0000, Simon Riggs wrote:
> >> >> On 12 December 2013 21:58, Fabrízio de Royes Mello
> >> >> <fabriziomello(at)gmail(dot)com> wrote:
> >> >> > Reviewing the committed patch I noted that the
"CheckForStandbyTrigger()"
> >> >> > after the delay was removed.
> >> >> >
> >> >> > If we promote the standby during the delay and don't check the
trigger
> >> >> > immediately after the delay, then we will replay undesired WALs
records.
> >> >> >
> >> >> > The attached patch add this check.
> >> >>
> >> >> I removed it because it was after the pause. I'll replace it, but
> >> >> before the pause.
> >> >
> >> > Doesn't after the pause make more sense? If somebody promoted while
we
> >> > were waiting, we want to recognize that before rolling forward? The
wait
> >> > can take a long while after all?
> >>
> >> That would change the way pause currently works, which is OOS for that
patch.
> >
> > But this feature isn't pause itself - it's imo something
> > independent. Note that we currently
> > a) check pause again after recoveryApplyDelay(),
> > b) do check for promotion if the sleep in recoveryApplyDelay() is
> > interrupted. So not checking after the final sleep seems confusing.
>
> I'm proposing the attached patch.
>
> This patch implements a consistent view of recovery pause, which is
> that when paused, we don't check for promotion, during or immediately
> after. That is user noticeable behaviour and shouldn't be changed
> without thought and discussion on a separate thread with a clear
> descriptive title. (I might argue in favour of it myself, I'm not yet
> decided).
>
In my previous message [1] I attach a patch equal to your ;-)
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-12-13 14:14:47 | Re: Changeset Extraction Interfaces |
Previous Message | Craig Ringer | 2013-12-13 13:52:43 | Re: WIP patch (v2) for updatable security barrier views |