Re: pg_upgrade --logfile option documentation

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
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:22:29
Message-ID: 1329941920-sup-776@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-02-22 20:32:09 Re: REASSIGN OWNED lacks support for FDWs
Previous Message Tom Lane 2012-02-22 20:20:35 Re: determining a type oid from the name