On Wed, May 27, 2015 at 10:06:03PM +0200, Christoph Berg wrote: > Re: Bruce Momjian 2015-05-27 <20150527174244.gb31...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers