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. +