I wasn't sure which list is better suited, so this is cross posted from pgsql-admin. -Thanks On Fri, Aug 21, 2009 at 10:46 AM, james bardin<jbardin@xxxxxx> wrote: > I have a working warm standby system, running 8.4 (thanks for urging > me to upgrade from the rehdat provided release). > One of the new requirements is going to be for (a non-DBA) admin to > easily swap services between the two servers for maintenance. > > 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. > > Is there a way to ship back the missing information from the recovery > process, without doing another base backup of data/ ? On Mon, Aug 24, 2009 at 11:34 AM, james bardin<jbardin@xxxxxx> wrote: > 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-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
