pg_upgrade resets timeline to 1

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.
(Timeline1 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@df7cb.de | http://www.df7cb.de/