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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Shigeru Hanada 2012-03-01 11:56:02 Re: pgsql_fdw, FDW for PostgreSQL server
Previous Message Fujii Masao 2012-03-01 02:39:53 Re: Client Messages