On Mar 7, 2012, at 11:39 PM, Bruce Momjian wrote: > On Thu, Mar 01, 2012 at 09:06:10PM -0500, Bruce Momjian wrote: >> OK, combining your and Robert's ideas, how about I have pg_upgrade write >> the server log to a file, and the pg_dump output to a file (with its >> stderr), and if pg_upgrade fails, I report the failure and mention those >> files. If pg_upgrade succeeds, I remove the files? pg_upgrade already >> creates temporary files that it removes on completion. > > OK, I have completed a rework of pg_upgrade logging. pg_upgrade had 4 > logging options, -g, -G, -l, and -v, and still it wasn't possible to get > useful logging. :-( > > What I have done with this patch is to remove -g, -G, and -l, and > unconditionally write to 4 log files in the current directory (in > addition to the 3 SQL files I already create). > > If pg_upgrade succeeds, the files are removed, but if it fails (or if > the new -r/retain option is used), the files remain. Here is a sample > failure when I create a plpgsql function in the old server, but truncate > plpgsql.so in the new server:
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 the /tmp directory so that one can compare results if the first pg_upgrade run had been errant. Cheers, M -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
