Re: pg_upgrade resets timeline to 1 - Mailing list pgsql-hackers

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