Re: pg_upgrade --logfile option documentation - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade --logfile option documentation
Date
Msg-id 20120222203729.GE17106@momjian.us
Whole thread Raw
In response to Re: pg_upgrade --logfile option documentation  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: pg_upgrade --logfile option documentation  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: determining a type oid from the name
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_upgrade --logfile option documentation