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
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
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
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
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
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
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
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
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
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.
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
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
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:
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
37 matches
Mail list logo
