On Wed, Feb 22, 2012 at 05:49:26PM -0500, Robert Haas wrote:
> On Wed, Feb 22, 2012 at 3:51 PM, Peter Eisentraut <peter_e(at)gmx(dot)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 /dev/null and NOT redirect stderr. If that generates too
> >> much chatter in non-failure cases, then let's adjust the output of the
> >> commands pg_upgrade is invoking until it doesn't.
> > That should be achievable for calls to psql and vacuumdb, say, but what
> > would you do with the server logs?
> I don't know. It might be less of an issue, though. I mean, IME,
> what typically happens is that psql fails to restore the dump, either
> because it can't connect to the new database or because it's confused
> by some stupid case that isn't handled well. So even if we could just
> improve the error handling to report those types of failures more
> transparently, I think it would be a big improvement.
Well, on Unix, it is easy to redirect the server logs to the same place
as the pg_upgrade logs. That doesn't help? How would we improve the
reporting of SQL restore failures?
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
+ It's impossible for everything to be true. +
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2012-02-22 23:40:25|
|Subject: Re: pg_upgrade --logfile option documentation|
|Previous:||From: Jeff Davis||Date: 2012-02-22 23:36:48|
|Subject: Re: SSI rw-conflicts and 2PC|