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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers