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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
