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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
