Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-12 Thread Bruce Momjian
On Thu, Mar 08, 2012 at 08:33:48PM -0500, Bruce Momjian wrote: OK, it seems people do care about keeping log files from multiple runs so I went with Tom's idea and have: - pg_upgrade run on Thu Mar 8 19:30:12 2012

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread A.M.
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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread Bruce Momjian
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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread A.M.
On Mar 8, 2012, at 10:00 AM, Bruce Momjian wrote: 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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread Tom Lane
Bruce Momjian br...@momjian.us writes: On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote: 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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread Bruce Momjian
On Thu, Mar 01, 2012 at 08:45:26AM -0500, Robert Haas wrote: On Wed, Feb 29, 2012 at 6:02 PM, Bruce Momjian br...@momjian.us wrote: Any ideas about improving the error reporting more generally, so that when reloading the dump fails, the user can easily see what went belly-up, even if they

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread Peter Eisentraut
On tor, 2012-03-08 at 10:06 -0500, A.M. wrote: 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. mktemps? I don't want to see some

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread A.M.
On Mar 8, 2012, at 4:37 PM, Peter Eisentraut wrote: On tor, 2012-03-08 at 10:06 -0500, A.M. wrote: 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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread Peter Eisentraut
On tor, 2012-03-08 at 16:44 -0500, A.M. wrote: The point of writing temp files to the /tmp/ directory is that they don't need to be cleaned up. I don't think so. If everyone just left their junk lying around in /tmp, it would fill up just like any other partition. -- Sent via pgsql-hackers

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread Bruce Momjian
On Thu, Mar 08, 2012 at 10:19:05AM -0500, Tom Lane wrote: Bruce Momjian br...@momjian.us writes: On Thu, Mar 08, 2012 at 08:34:53AM -0500, A.M. wrote: 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.

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-08 Thread Bruce Momjian
On Thu, Mar 08, 2012 at 11:59:59PM +0200, Peter Eisentraut wrote: On tor, 2012-03-08 at 16:44 -0500, A.M. wrote: The point of writing temp files to the /tmp/ directory is that they don't need to be cleaned up. I don't think so. If everyone just left their junk lying around in /tmp, it

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-07 Thread Bruce Momjian
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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-05 Thread Bruce Momjian
On Tue, Feb 28, 2012 at 09:45:41PM -0500, Bruce Momjian wrote: On Tue, Feb 28, 2012 at 02:15:30PM -0500, Bruce Momjian wrote: On Tue, Feb 28, 2012 at 01:24:45PM -0500, Robert Haas wrote: Running this script will delete the old cluster's data files:    

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-01 Thread Robert Haas
On Wed, Feb 29, 2012 at 6:02 PM, Bruce Momjian br...@momjian.us wrote: Any ideas about improving the error reporting more generally, so that when reloading the dump fails, the user can easily see what went belly-up, even if they didn't use -l? The only idea I have is to write the psql log to

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-01 Thread Peter Eisentraut
On ons, 2012-02-29 at 22:47 -0500, Bruce Momjian wrote: Hey, that's a good idea. I would always write the pg_dump output to a log file. If the dump succeeds, I remove the file, if not, I tell users to read the log file for details about the failure --- good idea. But we also need the server

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-01 Thread Bruce Momjian
On Thu, Mar 01, 2012 at 08:45:26AM -0500, Robert Haas wrote: On Wed, Feb 29, 2012 at 6:02 PM, Bruce Momjian br...@momjian.us wrote: Any ideas about improving the error reporting more generally, so that when reloading the dump fails, the user can easily see what went belly-up, even if they

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-03-01 Thread Bruce Momjian
On Thu, Mar 01, 2012 at 10:17:04PM +0200, Peter Eisentraut wrote: On ons, 2012-02-29 at 22:47 -0500, Bruce Momjian wrote: Hey, that's a good idea. I would always write the pg_dump output to a log file. If the dump succeeds, I remove the file, if not, I tell users to read the log file for

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-29 Thread Robert Haas
On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian br...@momjian.us wrote: OK, I have implemented both Roberts and Àlvaro's ideas in my patch. I only add the .old suffix to pg_controldata when link mode is used, and I now do it after the schema has been created (the most common failure case for

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-29 Thread Bruce Momjian
On Wed, Feb 29, 2012 at 04:34:24PM -0500, Robert Haas wrote: On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian br...@momjian.us wrote: OK, I have implemented both Roberts and Àlvaro's ideas in my patch. I only add the .old suffix to pg_controldata when link mode is used, and I now do it after

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-29 Thread A.M.
On Feb 29, 2012, at 6:02 PM, Bruce Momjian wrote: On Wed, Feb 29, 2012 at 04:34:24PM -0500, Robert Haas wrote: On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian br...@momjian.us wrote: OK, I have implemented both Roberts and Àlvaro's ideas in my patch. I only add the .old suffix to

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-29 Thread Bruce Momjian
On Wed, Feb 29, 2012 at 06:22:27PM -0500, A.M. wrote: On Feb 29, 2012, at 6:02 PM, Bruce Momjian wrote: On Wed, Feb 29, 2012 at 04:34:24PM -0500, Robert Haas wrote: On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian br...@momjian.us wrote: OK, I have implemented both Roberts and Àlvaro's

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-28 Thread Bruce Momjian
On Wed, Feb 22, 2012 at 03:37:29PM -0500, Bruce Momjian wrote: On Wed, Feb 22, 2012 at 05:22:29PM -0300, Alvaro Herrera wrote: Not sure about this. If the upgrades completes successfully and the file is not renamed at the last minute due to some error, that would be a problem as well,

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-28 Thread Robert Haas
On Tue, Feb 28, 2012 at 11:21 AM, Bruce Momjian br...@momjian.us wrote: On Wed, Feb 22, 2012 at 03:37:29PM -0500, Bruce Momjian wrote: On Wed, Feb 22, 2012 at 05:22:29PM -0300, Alvaro Herrera wrote: Not sure about this.  If the upgrades completes successfully and the file is not renamed at

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-28 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mar feb 28 15:24:45 -0300 2012: I think you should rename the old control file just before the step that says linking user relation files. That's the point after which it becomes unsafe to start the old cluster, right? Also, if it's not using link

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-28 Thread Bruce Momjian
On Tue, Feb 28, 2012 at 01:24:45PM -0500, Robert Haas wrote: Running this script will delete the old cluster's data files:    /usr/local/pgdev/pg_upgrade/delete_old_cluster.sh I think you should rename the old control file just before the step that says linking user relation files. That's

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-28 Thread Bruce Momjian
On Tue, Feb 28, 2012 at 03:48:03PM -0300, Alvaro Herrera wrote: Excerpts from Robert Haas's message of mar feb 28 15:24:45 -0300 2012: I think you should rename the old control file just before the step that says linking user relation files. That's the point after which it becomes

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-28 Thread Bruce Momjian
On Tue, Feb 28, 2012 at 02:15:30PM -0500, Bruce Momjian wrote: On Tue, Feb 28, 2012 at 01:24:45PM -0500, Robert Haas wrote: Running this script will delete the old cluster's data files:    /usr/local/pgdev/pg_upgrade/delete_old_cluster.sh I think you should rename the old control file

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-22 Thread Bruce Momjian
On Sun, Feb 19, 2012 at 01:13:10PM +0200, Peter Eisentraut wrote: The documentation of the pg_upgrade -l/--logfile option never made much sense to me: -l, --logfile=FILENAMElog session activity to file I don't know what session means for pg_upgrade, so I never used it. What it

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-22 Thread Bruce Momjian
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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-22 Thread Alvaro Herrera
Excerpts from Bruce Momjian's message of mié feb 22 17:01:10 -0300 2012: On Sun, Feb 19, 2012 at 01:24:34PM -0500, Robert Haas wrote: 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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-22 Thread Bruce Momjian
On Wed, Feb 22, 2012 at 05:22:29PM -0300, Alvaro Herrera wrote: Excerpts from Bruce Momjian's message of mié feb 22 17:01:10 -0300 2012: On Sun, Feb 19, 2012 at 01:24:34PM -0500, Robert Haas wrote: One pretty obvious improvement would be: if pg_upgrade fails after renaming the control

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-22 Thread Peter Eisentraut
On ons, 2012-02-22 at 14:38 -0500, Bruce Momjian wrote: How about? -l, --logfile=FILENAMElog internal activity to file That sounds better. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-22 Thread Peter Eisentraut
On sön, 2012-02-19 at 13:24 -0500, Robert Haas wrote: 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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-22 Thread Robert Haas
On Wed, Feb 22, 2012 at 3:51 PM, Peter Eisentraut pete...@gmx.net wrote: On sön, 2012-02-19 at 13:24 -0500, Robert Haas wrote: 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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-22 Thread Bruce Momjian
On Wed, Feb 22, 2012 at 05:49:26PM -0500, Robert Haas wrote: On Wed, Feb 22, 2012 at 3:51 PM, Peter Eisentraut pete...@gmx.net wrote: On sön, 2012-02-19 at 13:24 -0500, Robert Haas wrote: But I also think the logging needs improvement.  Right now, we studiously redirect both stdout and

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-22 Thread Bruce Momjian
On Wed, Feb 22, 2012 at 10:50:07PM +0200, Peter Eisentraut wrote: On ons, 2012-02-22 at 14:38 -0500, Bruce Momjian wrote: How about? -l, --logfile=FILENAMElog internal activity to file That sounds better. Done. -- Bruce Momjian br...@momjian.ushttp://momjian.us

[HACKERS] pg_upgrade --logfile option documentation

2012-02-19 Thread Peter Eisentraut
The documentation of the pg_upgrade -l/--logfile option never made much sense to me: -l, --logfile=FILENAMElog 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

Re: [HACKERS] pg_upgrade --logfile option documentation

2012-02-19 Thread Robert Haas
On Sun, Feb 19, 2012 at 6:13 AM, Peter Eisentraut pete...@gmx.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