Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade --logfile option documentation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade --logfile option documentation
Date: 2012-02-19 18:24:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Feb 19, 2012 at 6:13 AM, Peter Eisentraut <peter_e(at)gmx(dot)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

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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-02-19 18:33:11
Subject: Re: wal_buffers
Previous:From: Robert HaasDate: 2012-02-19 18:08:28
Subject: Re: wal_buffers

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group