On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote: > > 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
Yes. I was afraid that continually appending to a log file on every run would be too confusing. I could do only appends, or number the log files, that those seemed confusing. > the /tmp directory so that one can compare results if the first pg_upgrade > run had been errant. You would have to copy the file to a new name before re-running pg_upgrade. The only reason I truncate them on start is that I am appending to them in many places in the code, and it was easier to just truncate them on start rather than to remember where I first write to them. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
