Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade --logfile option documentation

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>,Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade --logfile option documentation
Date: 2012-02-22 20:37:29
Message-ID: 20120222203729.GE17106@momjian.us (view raw or flat)
Thread:
Lists: 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(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2012-02-22 20:50:07
Subject: Re: pg_upgrade --logfile option documentation
Previous:From: Andrew DunstanDate: 2012-02-22 20:32:43
Subject: Re: determining a type oid from the name

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group