pg_upgrade resets timeline to 1

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

Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/