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 по дате отправления: