Re: pg_upgrade --logfile option documentation

On Wed, Feb 22, 2012 at 05:22:29PM -0300, Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of mié feb 22 17:01:10 -0300 2012:
> > On Sun, Feb 19, 2012 at 01:24:34PM -0500, Robert Haas wrote:
>
> > > One pretty obvious improvement would be: if pg_upgrade fails after
> > > renaming the control file for the old cluster out of the way - say,
> > > while loading the schema dump into the new cluster - have it RENAME
> > > THE OLD CONTROL FILE BACK before exiting. But I also think the
> >
> > The behavior you are seeing now is the paranoia inherent in pg_upgrade's
> > design. Now that pg_upgrade is being used more, perhaps that needs to
> > be relaxed.
> >
> > However, remember we rename that control file to prevent the old cluster
> > from being run accidentally, which is particular important in link mode.
>
> ... but if the upgrade failed, clearly this shouldn't be a problem. I
> agree with Robert, and was bit by this last week -- in case of any error
> during the procedure, the control file should be renamed back to its
> original name.
>
> > There might be some error cases that still would not restore the
> > location of that file if we have a revert behavior on error. A more
> > normal behavior would be for pg_upgrade to rename the control file only
> > when the upgrade completes successfully.
>
> Not sure about this. If the upgrades completes successfully and the
> file is not renamed at the last minute due to some error, that would be
> a problem as well, because now the old cluster would happily run and
> perhaps corrupt the data files from under the new cluster.

Well, the basic problem is that the user, before pg_upgrade started,
installed a new cluster that works. If we rename the old control, but
rename it back on failure, there are cases we will miss, kill like -9 or
a server crash, and it will not be obvious to them that the control file
was renamed.

Of course, if we only rename on success, and there is kill -9 or server
crash, the old cluster is still start-able, like the new one.

One good argument for the rename early is that on a server crash, the
system is probably going to restart the database automatically, and that
means the old server.

Right now we have a clear message that they need to rename the control
file to start the old server. Not sure what the new wording would look
like --- let me try.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +