From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marco Nenciarini <mnencia(at)debian(dot)org> |
Subject: | Re: pg_upgrade resets timeline to 1 |
Date: | 2015-05-28 08:13:14 |
Message-ID: | 20150528081313.GA22629@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Re: Bruce Momjian 2015-05-28 <20150527221607(dot)GA7964(at)momjian(dot)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.
Christoph
--
cb(at)df7cb(dot)de | http://www.df7cb.de/
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-05-28 08:14:16 | Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension |
Previous Message | Heikki Linnakangas | 2015-05-28 07:55:29 | Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension |