On Wed, May 27, 2015 at 10:06:03PM +0200, Christoph Berg wrote:
> 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.
Well, if you used pg_dump/pg_restore, you would have had even larger
problems as the file names would have matched.
> > 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.
That is an open question, whether pg_upgrade should try to avoid this,
even if other methods do not, or should we better document not to do
this.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
