On Sat, Aug 21, 2010 at 12:45:44PM -0400, Bruce Momjian wrote:
> Derrick Rice wrote:
> > I've been reading up on the documentation for WAL shipping and warm standby
> > configuration. One concern that I have (a common one, I'm sure) is that it
> > seems that after bringing a standby server up as primary, other standby
> > servers (including the original primary) need to be rebased before they can
> > read the new primary's WALs in continuous recovery mode.
> >
> > It seems that the cause of this is a change to the leading digit of the WAL
> > files:
> >
> > http://archives.postgresql.org/pgsql-general/2010-03/msg00985.php
> > http://archives.postgresql.org/pgsql-admin/2009-08/msg00179.php
> >
> > I was hoping that someone would shed some light on this situation with a
> > technical explanation. It's not clear to me why the WAL files are
> > incompatible or why the digit increases. What does that first digit mean to
> > postgresql? Is it possible to have the restore_command ignore the leading
> > digit?
>
> The first digit in the WAL filename is the timeline.
>
> I think we need to figure out a better way to promote slaves when there
> is a new master, but no one has done the research yet.
In Postgresql 8.0, I used to rely on what seemed to be a bug in it when
it didn't switch timelines if restore_command returned a non-zero status,
and that worked like a charm more than once for me. Can switching time-
lines be just made optional in recovery.conf or depending on what
restore_command returns? Sorry if I'm missing any important architectural
points here.
Yar
