Re: pg_upgrade resets timeline to 1

On 27 May 2015 at 18:42, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Wed, May 27, 2015 at 05:40:09PM +0200, Christoph Berg wrote:
> > commit 4c5e060049a3714dd27b7f4732fe922090edea69
> > Author: Bruce Momjian <bruce(at)momjian(dot)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