=0A=
=0A=
----------------------------------------=0A=
> Date: Mon=2C 25 Apr 2016 23:03:23 +0900=0A=
> Subject: Re: [BUGS] BUG #14109: pg_rewind fails to update target control =
file in one scenario=0A=
> From: michael.paquier@gmail.com=0A=
> To: johnlumby@hotmail.com=0A=
> CC: pgsql-bugs@postgresql.org=0A=
>=0A=
> On Mon=2C Apr 25=2C 2016 at 10:48 PM=2C John Lumby <johnlumby@hotmail.com=
> wrote:=0A=
>>=0A=
>> Note the difference in timeline=0A=
>=0A=
> Yes=2C and? System A is still on its previous timeline 11=2C and will jum=
p=0A=
> to timeline 12 once it has connected back. That's possible since 9.3.=0A=
=0A=
Answering your "and?" : In my testing=2C=A0 =0A=
=A0 =A0 =A0 =A0 "and no WAL replicated from B=2C new Primary =2C to A =2C n=
ew Standby".=0A=
That is why I concluded there is a bug.=0A=
Also on System A (new Standby) timeline did not jump up to 12=2C=A0 it rema=
ined at 11.=0A=
Are you indicating that the admin (me) needs to do something to make that h=
appen?=0A=
If so what?=0A=
=0A=
>=0A=
>> and then=2C as I described=2C no WAL is replicated from B to A.=0A=
>> Did you try this scenario yourself?=0A=
>=0A=
> Yes.=0A=
=0A=
And did you perform updates on System B (new Primary)=0A=
and then observe them replicated to System A?=0A=
I consistently see that *not* happening.=0A=
=0A=
>=0A=
>> I hope you agree it is a bug?=0A=
>=0A=
> No. In this case pg_rewind is a no-op: system A was shut down *before*=0A=
> B was promoted=2C so it knows about the shutdown checkpoint record of=0A=
> system A. No rewind would be needed here. One potential issue with=0A=
=0A=
Yes=2C=A0 no rewind is needed=2C=A0 I agree.=A0=A0 But=2C=A0 as you stated =
earlier=2C=0A=
the timeline on System A needs to be incremented.=0A=
So the question is=2C=A0 what is supposed to make that happen?=0A=
=0A=
>=0A=
> Again there is no bug here.=0A=
> --=0A=
> Michael=0A=
=