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

Re: pg_upgrade --logfile option documentation

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade --logfile option documentation
Date: 2012-03-01 03:47:04
Message-ID: 20120301034704.GA15953@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Feb 29, 2012 at 06:22:27PM -0500, A.M. wrote:
> 
> On Feb 29, 2012, at 6:02 PM, Bruce Momjian wrote:
> 
> > On Wed, Feb 29, 2012 at 04:34:24PM -0500, Robert Haas wrote:
> >> On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >>> OK, I have implemented both Roberts and Àlvaro's ideas in my patch.
> >>> I only add the .old suffix to pg_controldata when link mode is used, and
> >>> I now do it after the schema has been created (the most common failure
> >>> case for pg_upgrade), and just before we actually link files --- both
> >>> very good ideas.
> >> 
> >> Thanks for working on this.  I think this will be a significant
> >> usability improvement.
> > 
> > Glad I got such good feedback and ideas.
> > 
> >> Any ideas about improving the error reporting more generally, so that
> >> when reloading the dump fails, the user can easily see what went
> >> belly-up, even if they didn't use -l?
> > 
> > The only idea I have is to write the psql log to a temporary file and
> > report the last X lines from the file in case of failure.  Does that
> > help?
> > 
> 
> 
> Perhaps pg_upgrade can print the path to the temp file containing the
> log and instruct the user to look there for more detail.

Hey, that's a good idea.  I would always write the pg_dump output to a
log file.  If the dump succeeds, I remove the file, if not, I tell users
to read the log file for details about the failure --- good idea.

-- 
  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: Shigeru HanadaDate: 2012-03-01 11:56:02
Subject: Re: pgsql_fdw, FDW for PostgreSQL server
Previous:From: Fujii MasaoDate: 2012-03-01 02:39:53
Subject: Re: Client Messages

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