| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_upgrade --logfile option documentation |
| Date: | 2012-03-02 02:04:20 |
| Message-ID: | 20120302020420.GA11306@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 01, 2012 at 08:45:26AM -0500, Robert Haas wrote:
> On Wed, Feb 29, 2012 at 6:02 PM, Bruce Momjian <bruce(at)momjian(dot)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 a temporary file and
> > report the last X lines from the file in case of failure. Does that
> > help?
>
> Why not just redirect stdout but not stderr? If there are error
> messages, surely we want the user to just see those.
Well, I think sending the error messages to the user but stdout to a
file will leave users confused because it will be unclear which SQL
statement generated the error.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2012-03-02 02:06:10 | Re: pg_upgrade --logfile option documentation |
| Previous Message | Robert Haas | 2012-03-02 01:46:18 | Re: 16-bit page checksums for 9.2 |