warm standby and reciprocating failover

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(at)bu(dot)edu> 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(at)bu(dot)edu> 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