On Thu, Jul 26, 2012 at 10:40 AM, Bruce Momjian <br...@momjian.us> wrote: > 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?
Having them the same is clearly sufficient, but only if ALL the files are the same. You seem to be taking it on faith that the data files backing non-system tables will be the same, or close enough to the same, that we can just not worry about those. I find that when I don't worry about things, they break. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
