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@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 /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@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +