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
- 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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2012-02-19 18:33:11|
|Subject: Re: wal_buffers |
|Previous:||From: Robert Haas||Date: 2012-02-19 18:08:28|
|Subject: Re: wal_buffers|