| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| 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-01 13:45:26 |
| Message-ID: | CA+Tgmoa4L8M7J-L+ntVOy-sQ5=GDWo4CSLppw6-bWWA68XwYzw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-03-01 13:47:18 | Re: Parameterized-path cost comparisons need some work |
| Previous Message | Robert Haas | 2012-03-01 12:41:04 | Re: 16-bit page checksums for 9.2 |