Yaroslav Tykhiy wrote:
> 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.
Sorry, I don't know. I think the timelines are only there for safety if
you have to fall back to the previous timeline, and to prevent timeline
mixing.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +