Re: warm standby and reciprocating failover.

On Fri, Aug 21, 2009 at 10:46 AM, james bardin<jbardin(at)bu(dot)edu> wrote:

> The first move runs easily as expected- postgres ships the last
> partial wal immediately on shutdown, trigger the standby and we're up.
> I'm now running into issues bringing the first server back up in
> standby mode. After the second server finishes recovery, the major
> number of the wal files is incremented (say from  00000001 to
> 00000002), and the 00000002.history file is shipped back to the first
> server. The first server however is still looking for 00000001x files.
>

So I've been experimenting with this timeline problem without any success.
Is it possible that there are changes made during recovery that aren't logged?

I tried recovery_target_timeline='X' on the standby, where X is the
new timeline created after recovery on the new master. This fails,
with some "unexpected timeline ID" lines and a
PANIC: could not locate a valid checkpoint record

I also tried using recovery_target_timeline='latest'. This fell back
gracefully to an earlier state, but changes were lost. Also, it never
waited on pg_standby, and finished recovering immediately.

Although it doesn't solve this problem, can pg_standby be used with
recovery_target_timeline='latest', or should I file a bug?

Thanks
-jim