On Fri, Aug 21, 2009 at 10:46 AM, james bardin<jbardin@xxxxxx> 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
