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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
