On Thu, May 28, 2015 at 10:13:14AM +0200, Christoph Berg wrote: > Re: Bruce Momjian 2015-05-28 <20150527221607.ga7...@momjian.us> > > Well, if you used pg_dump/pg_restore, you would have had even larger > > problems as the file names would have matched. > > True, but even here it's possible that files get overwritten. If you > had a server running on TL 1 for files 0001001..00010020, and then did > a PITR at location 10, you'll have a server writing to 00020010. > If you pg_upgrade that, it will keep its WAL position, but start at 1 > again, overwriting files 00010011 and following. > > > > > 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. > > Actually, if initdb could be told to start at an arbitrary timeline, > it would be trivial to avoid the problem with pg_dump upgrades as > well.
Yes, that would make sense. Perhaps we should revisit this for 9.6. -- 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