Re: Bruce Momjian 2015-05-27 <20150527174244.GB31835@momjian.us>
> > 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.
I guess I could rename all the barman server definitions to
$server-$version, yes. My point is mostly that if I chose to continue
to use the same backup store (knowing that I can't recover across the
upgrade point), pg_upgrade shouldn't make things more complicated than
they need to. This change broke barman and probably most of the other
WAL backup helpers out there, and IMHO shouldn't have been backpatched
to released branches.
> 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.
pg_upgrade-style upgrades have a chance to know which timeline to use.
That other methods have less knowledge about the "old" system
shouldn't mean that pg_upgrade shouldn't care.
(Wishlist idea: an initdb option to chose the timeline to start with)
Christoph
--
cb@df7cb.de | http://www.df7cb.de/
