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

On Sun, Feb 19, 2012 at 6:13 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> The documentation of the pg_upgrade -l/--logfile option never made much
> sense to me:
>
>  -l, --logfile=FILENAME        log session activity to file
>
> I don't know what "session" means for pg_upgrade, so I never used it.
>
> What it actually does is log the output of all the programs that
> pg_upgrade calls internally, such as pg_ctl, psql, vacuumdb,
> pg_resetxlog, to the specified file, which is quite useful for analyzing
> errors such as
>
> unable to connect to new postmaster started with the command: "/usr/lib/postgresql/9.1/bin/pg_ctl" -w -l "/dev/null"
-D"/var/lib/postgresql/9.1/main" -o "-p 5433 -b" start >> "/dev/null" 2>&1 
>
> where -l would have put something in the place of /dev/null.
>
> So what might be a better wording for this option?  Something like "log
> output of internally called programs to file"?

I don't think we should be that specific, because we might someday
want pg_upgrade itself to write messages to that file as well, even if
it doesn't today.  I agree that the phrase "session activity" is a bit
misleading.

As a more general comment, I think that the way pg_upgrade does
logging right now is absolutely terrible.  IME, it is utterly
impossible to understand what has gone wrong with pg_upgrade without
looking at the log file.  And by default, no log file is created.  So
typically what happens is:

- I run pg_upgrade.  It fails.
- I rename the control file from the old cluster back to its original name.
- I rerun pg_upgrade, this time with -l.  It fails again.
- I read the log file, figure out what the problem is, and correct it.
- I rename the control file from the old cluster back to its original
name, again.
- I run pg_upgrade a third time.
- On a good day, it works, else go to step 5.

One pretty obvious improvement would be: if pg_upgrade fails after
renaming the control file for the old cluster out of the way - say,
while loading the schema dump into the new cluster - have it RENAME
THE OLD CONTROL FILE BACK before exiting.  But I also think the
logging needs improvement.  Right now, we studiously redirect both
stdout and stderr to /dev/null; maybe it would be better to redirect
stdout to /dev/null and NOT redirect stderr.  If that generates too
much chatter in non-failure cases, then let's adjust the output of the
commands pg_upgrade is invoking until it doesn't.  The actual cause of
the failure, rather than pg_upgrade's fairly-useless gloss on it,
ought to be visible right away, at least IMHO.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company