On 27 May 2015 at 18:42, Bruce Momjian <br...@momjian.us> wrote: > On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote: > > commit 4c5e060049a3714dd27b7f4732fe922090edea69 > > Author: Bruce Momjian <br...@momjian.us> > > Date: Sat May 16 00:40:18 2015 -0400 > > > > pg_upgrade: force timeline 1 in the new cluster > > > > Previously, this prevented promoted standby servers from being > upgraded > > because of a missing WAL history file. (Timeline 1 doesn't need a > > history file, and we don't copy WAL files anyway.) > > > > Pardon me for starting a fresh thread, but I couldn't find where this > > was discussed. > > > > I've just had trouble getting barman to work again after a 9.1->9.4.2 > > upgrade, and I think part of the problem was that the WAL for this > > cluster got reset from timeline 2 to 1, which made barman's incoming > > WALs processor drop the files, probably because the new filename > > 0001... is now "less" than the 0002... before. > > > > I don't expect to be able to recover through a pg_upgrade operation, > > but pg_upgrade shouldn't make things more complicated than they should > > be for backup tools. (If there's a problem with the history files, > > shouldn't pg_upgrade copy them instead?) > > > > In fact, I'm wondering if pg_upgrade shouldn't rather *increase* the > > timeline to make sure the archive_command doesn't clobber any files > > from the old cluster when reused in the new cluster? > > > > https://bugs.debian.org/786993 > > Uh, WAL files and WAL history files are not compatible across PG major > versions so you should never be fetching them after a major upgrade. I > have noticed some people are putting their WAL files in directories with > PG major version numbers to avoid this problem. > > We could have pg_upgrade increment the timeline and allow for missing > history files, but that doesn't fix problems with non-pg_upgrade > upgrades, which also should never be sharing WAL files from previous > major versions. >
Maybe, but I thought we had a high respect for backwards compatibility and we clearly just broke quite a few things that didn't need to be broken. Hmm, it looks like the change to TimeLine 1 is just a kludge anyway. The rule that TimeLine 1 doesn't need a history file is itself a hack. What we should be saying is that the last timeline doesn't need a history file. Then no change is needed here. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
