Re: pg_upgrade --logfile option documentation - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade --logfile option documentation
Date
Msg-id 20120308150025.GB29911@momjian.us
Whole thread Raw
In response to Re: pg_upgrade --logfile option documentation  ("A.M." <agentm@themactionfaction.com>)
Responses Re: pg_upgrade --logfile option documentation  ("A.M." <agentm@themactionfaction.com>)
Re: pg_upgrade --logfile option documentation  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_stat_statements and planning time
Next
From: "A.M."
Date:
Subject: Re: pg_upgrade --logfile option documentation