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 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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
