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
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
On Thu, Mar 08, 2012 at 10:19:05AM -0500, Tom Lane wrote:
> Bruce Momjian 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
> >>
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 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
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
On Thu, Mar 01, 2012 at 08:45:26AM -0500, Robert Haas wrote:
> On Wed, Feb 29, 2012 at 6:02 PM, Bruce Momjian 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 u
Bruce Momjian 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 been 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 th
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_
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 fail
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
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:
> > > > /usr/local/pgdev/pg_upgra
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 fil
On Thu, Mar 01, 2012 at 08:45:26AM -0500, Robert Haas wrote:
> On Wed, Feb 29, 2012 at 6:02 PM, Bruce Momjian 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 u
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 ser
On Wed, Feb 29, 2012 at 6:02 PM, Bruce Momjian 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 a tempora
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 wrote:
> >>> OK, I have implemented both Roberts and Àlvaro's ideas i
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 wrote:
>>> OK, I have implemented both Roberts and Àlvaro's ideas in my patch.
>>> I only add the .old suffix to pg_controldata when
On Wed, Feb 29, 2012 at 04:34:24PM -0500, Robert Haas wrote:
> On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian 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
On Tue, Feb 28, 2012 at 9:45 PM, Bruce Momjian 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 pg_upgrade), an
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 con
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 be
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".
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 11:21 AM, Bruce Momjian 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 the last
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 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 http://momjian.us
Enter
On Wed, Feb 22, 2012 at 05:49:26PM -0500, Robert Haas wrote:
> On Wed, Feb 22, 2012 at 3:51 PM, Peter Eisentraut 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
On Wed, Feb 22, 2012 at 3:51 PM, Peter Eisentraut 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 /dev/n
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 chatt
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:
http://www.postgresql.org/m
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 t
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
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 de
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.
>
On Sun, Feb 19, 2012 at 6:13 AM, Peter Eisentraut 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 it ac
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 call
38 matches
Mail list logo
