Date: Fri, 13 Dec 2013 14:22:03 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: =?iso-8859-1?Q?Fabr=EDzio?= Mello <fabriziomello@gmail.com>,
 Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>,
 Pavel Stehule <pavel.stehule@gmail.com>,
 Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Time-Delayed Standbys
Message-ID: <20131213132203.GJ29402@awork2.anarazel.de>
References: 
 <CA+U5nMJp5WEqEhjn8S7sA5LahHQUuLDoXpQF2qQL=-TL9gwnKg@mail.gmail.com>
 <3398.1386859959@sss.pgh.pa.us>
 <CA+TgmoaZa3D_RkPT+XZsEzMi-KvFu2NyLXD96RKy=L+qMh4oUQ@mail.gmail.com>
 <CA+U5nMJUF853tp-Gt8BeykeZ6wUv55bb8gitJW5tFTTuSQkYSA@mail.gmail.com>
 <CA+U5nMKXvEAqiPdgb-Rc_066xRVGCuzqS13L54go3u39KLZezg@mail.gmail.com>
 <CAFcNs+ovtwDkXsqPx=xcNEg2hy3jekoga89ytqDG12UwLq527g@mail.gmail.com>
 <CAFcNs+qD0AJ=qzhsHD9+v_Mhz0RTBJ=cJPCT_T=uT_JvvnC1FQ@mail.gmail.com>
 <CA+U5nMLhhPQ_FX-TuBLfvn0OMsPY-URZpE_CKtdROFXXoST=Vg@mail.gmail.com>
 <20131213115858.GI29402@awork2.anarazel.de>
 <CA+U5nMLRgEqvjyNnWGEO3pwAafBybtmvF6++OqDQHSasdnSqPg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: 
 <CA+U5nMLRgEqvjyNnWGEO3pwAafBybtmvF6++OqDQHSasdnSqPg@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2013-12-13 13:09:13 +0000, Simon Riggs wrote:
> On 13 December 2013 11:58, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2013-12-13 11:56:47 +0000, Simon Riggs wrote:
> >> On 12 December 2013 21:58, Fabr=EDzio de Royes Mello
> >> <fabriziomello@gmail.com> wrote:
> >> > Reviewing the committed patch I noted that the "CheckForStandbyTrigg=
er()"
> >> > after the delay was removed.
> >> >
> >> > If we promote the standby during the delay and don't check the trigg=
er
> >> > immediately after the delay, then we will replay undesired WALs reco=
rds.
> >> >
> >> > 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?
>=20
> That would change the way pause currently works, which is OOS for that pa=
tch.

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.

Greetings,

Andres Freund

--=20
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers