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:

Reply via email to