Philippe Amelant wrote:
>>> So i was thinking it was just a reconnect to the sender (and I can see
>>> the standby trying to reconnect in the log)
>> Hmmm. I think I was too quick when I said no.
>>
>> If you ship the WAL archives including the "history" file to the
>> standby, then the standby should be able to recover across the
>> timeline change from the archives (if you have recovery_target_timeline
>> set to "latest" in recovery.conf) and then reestablish streaming
>> replication.
>>
>> I never tried that though.
>>
>> (The patch I quoted above would allow the timeline change via
>> streaming replication.)
> You're right
> I added
> recovery_target_timeline='latest'
>
> in the recovery.conf then I promoted the standby.
>
> The replication on the second standby stopped with a message
> complaining about timeline.
>
> Then I copied the archived wal from the new master to the (stopped)
> standby (in pg_xlog)
>
> The standby restarted on the new timeline and the datas seem to be ok.
>
> I also tried to just copy the last 000000X.history in pg_xlog and it
> work too.
> I suppose this could fail if max_wal_keep_segment is too low
>
> Thanks you very much for your help.
> Could you just point me where you found this information in the doc ?
I didn't consult the documentation, I used what I know of how
WAL recovery and streaming replication work...
However, I find the following in
http://www.postgresql.org/docs/current/static/recovery-target-settings.html
recovery_target_timeline
[...]
Setting this to latest recovers to the latest timeline found in the archive,
which is useful in a standby server.
Yours,
Laurenz Albe
