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-08 15:00:25
Message-ID: 20120308150025.GB29911@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote:
>
> On Mar 7, 2012, at 11:39 PM, Bruce Momjian wrote:
>
> > On Thu, Mar 01, 2012 at 09:06:10PM -0500, Bruce Momjian wrote:
> >> OK, combining your and Robert's ideas, how about I have pg_upgrade write
> >> the server log to a file, and the pg_dump output to a file (with its
> >> stderr), and if pg_upgrade fails, I report the failure and mention those
> >> files. If pg_upgrade succeeds, I remove the files? pg_upgrade already
> >> creates temporary files that it removes on completion.
> >
> > OK, I have completed a rework of pg_upgrade logging. pg_upgrade had 4
> > logging options, -g, -G, -l, and -v, and still it wasn't possible to get
> > useful logging. :-(
> >
> > What I have done with this patch is to remove -g, -G, and -l, and
> > unconditionally write to 4 log files in the current directory (in
> > addition to the 3 SQL files I already create).
> >
> > If pg_upgrade succeeds, the files are removed, but if it fails (or if
> > the new -r/retain option is used), the files remain. Here is a sample
> > failure when I create a plpgsql function in the old server, but truncate
> > plpgsql.so in the new server:
>
> It looks like the patch will overwrite the logs in the current working
> directory, for example, if pg_upgrade is run twice in the same place. Is
> that intentional? I had imagined that the logs would have been dumped in

Yes. I was afraid that continually appending to a log file on every run
would be too confusing. I could do only appends, or number the log
files, that those seemed confusing.

> the /tmp directory so that one can compare results if the first pg_upgrade
> run had been errant.

You would have to copy the file to a new name before re-running
pg_upgrade.

The only reason I truncate them on start is that I am appending to them
in many places in the code, and it was easier to just truncate them on
start rather than to remember where I first write to them.

--
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 A.M. 2012-03-08 15:06:28 Re: pg_upgrade --logfile option documentation
Previous Message Tom Lane 2012-03-08 14:44:06 Re: pg_stat_statements and planning time