From: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com> |
---|---|
To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade --logfile option documentation |
Date: | 2012-03-08 13:34:53 |
Message-ID: | 73C46237-6DE1-4788-990E-F151DF6E8E7F@themactionfaction.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-03-08 13:40:28 | Re: Client Messages |
Previous Message | Peter Geoghegan | 2012-03-08 13:31:32 | Re: pg_stat_statements and planning time |