| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Tighten error control for OpenTransientFile/CloseTransientFile |
| Date: | 2019-03-01 22:05:54 |
| Message-ID: | 09ffc3a3-0e1d-91c6-7748-890b1829469a@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2/28/19 9:33 PM, Michael Paquier wrote:
> Hi all,
>
> Joe's message here has reminded me that we have lacked a lot of error
> handling around CloseTransientFile():
> https://www.postgresql.org/message-id/c49b69ec-e2f7-ff33-4f17-0eaa4f2cef27@joeconway.com
>
> This has been mentioned by Alvaro a couple of months ago (cannot find
> the thread about that at quick glance), and I just forgot about it at
> that time. Anyway, attached is a patch to do some cleanup for all
> that:
> - Switch OpenTransientFile to read-only where sufficient.
> - Add more error handling for CloseTransientFile
> A major take of this patch is to make sure that the new error messages
> generated have an elevel consistent with their neighbors.
>
> Just on time for this last CF. Thoughts?
Seems like it would be better to modify the arguments to
CloseTransientFile() to include the filename being closed, errorlevel,
and fail_on_error or something similar. Then all the repeated ereport
stanzas could be eliminated.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matt Pulver | 2019-03-01 22:19:45 | Re: Infinity vs Error for division by zero |
| Previous Message | Thomas Munro | 2019-03-01 22:04:06 | Re: Drop type "smgr"? |