Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Дата
Msg-id 20160621161534.GI24184@momjian.us
обсуждение исходный текст
Ответ на Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Jun 21, 2016 at 12:12:34PM -0400, Robert Haas wrote:
> >> > What is confusing you?
> >>
> >> I don't think I'm confused.  Sure, you can do that, but the effects of
> >> any writes performed on the new cluster will not be there when you
> >> revert back to the old cluster.  So you will have effectively lost
> >> data, unless you somehow have the ability to re-apply all of those
> >> write transactions somehow.
> >
> > Yes, that is true.  I assume _revert_ means something really bad
> > happened and you don't want those writes because they are somehow
> > corrupt.
> 
> I think that it's pretty likely you could, say, upgrade to a new major
> release, discover that it has a performance problem or some other bug
> that causes a problem for you, and want to go back to the older
> release.  There's not really an easy way to do that, because a pg_dump
> taken from the new system might not restore on the older one.  Logical
> replication - e.g. Slony - can provide a way, but we don't have
> anything in core that can do it.

Yes, there is data loss in a rollback to the old cluster, no question.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Choosing the cheapest optimizer cost