On Fri, Aug 21, 2009 at 10:46 AM, james bardin<jbardin@bu.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