Re: pg_upgrade --logfile option documentation

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "A.M." <agentm@themactionfaction.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-09T01:33:48Z
Lists: pgsql-hackers

Attachments

On Thu, Mar 08, 2012 at 10:19:05AM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote:
> >> 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.
> 
> Use one (set of) files, and always append, but at the beginning of each
> run print "\npg_upgrade starting at [timestamp]\n\n".  Should make it
> reasonably clear, while not losing information.

OK, it seems people do care about keeping log files from multiple runs
so I went with Tom's idea and have:

	-----------------------------------------------------------------
	  pg_upgrade run on Thu Mar  8 19:30:12 2012
	-----------------------------------------------------------------
	
	Performing Consistency Checks
	-----------------------------

Updated patch attached.

FYI, in retain mode, these are the files left in the current directory:

	delete_old_cluster.sh
	pg_upgrade_dump_all.sql
	pg_upgrade_dump_db.sql
	pg_upgrade_dump_globals.sql
	pg_upgrade_internal.log
	pg_upgrade_restore.log
	pg_upgrade_server.log
	pg_upgrade_utility.log

I will address the idea of using /tmp in another email.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +