Re: Using pg_upgrade on log-shipping standby servers
От | Bruce Momjian |
---|---|
Тема | Re: Using pg_upgrade on log-shipping standby servers |
Дата | |
Msg-id | 20120726144013.GI21271@momjian.us обсуждение исходный текст |
Ответ на | Re: Using pg_upgrade on log-shipping standby servers (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Using pg_upgrade on log-shipping standby servers
|
Список | pgsql-hackers |
On Thu, Jul 26, 2012 at 10:26:53AM -0400, Robert Haas wrote: > > Well, then that would call for another list of files. > > I cannot escape the feeling that if we go down this route in any form > we're going to spend years tracking down data-loss-inducing bugs. The > ones we have on the master are bad enough, but doing it on the standby > is almost worse because (1) few enough people will use this > functionality that we won't get many bug reports even if it's badly > broken and (2) people who are affected may not discover it until > something bad has already happened on the master. I don't hear anyone > thinking very hard about ways that the master could be different from > the standby, and without a lot of careful thought on that topic I > think this is all kinds of bad news. Just to take one example, how > are you going to ensure that the standby has replayed all the WAL that > the master generated prior to the upgrade? If the answer is "shut > everything down cleanly and hope for the best", color me unimpressed. > > IMV, pg_upgrade is not yet sufficiently reliable that we should be > looking for new projects that seem certain to make it less reliable. The script has to make the primary/standby identical, and guarantee that. That is why one list and removing new standby files is necessary. Are you saying having the primary/standby identical is impossible/unreliable, or that having them the same is insufficent? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: