Re: pg_upgrade --logfile option documentation

On Sun, Feb 19, 2012 at 01:24:34PM -0500, Robert Haas wrote:
> 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

The behavior you are seeing now is the paranoia inherent in pg_upgrade's
design. Now that pg_upgrade is being used more, perhaps that needs to
be relaxed.

However, remember we rename that control file to prevent the old cluster
from being run accidentally, which is particular important in link mode.
There might be some error cases that still would not restore the
location of that file if we have a revert behavior on error. A more
normal behavior would be for pg_upgrade to rename the control file only
when the upgrade completes successfully.

> 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.

Well, we have a -d option for debug; we could modify that to have debug
levels. Also, from the command line, it is difficult to have multiple
process write into a single file, so that isn't going work to have
pg_upgrade and the server logging to the same file on Windows.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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