Re: Tighten error control for OpenTransientFile/CloseTransientFile - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Tighten error control for OpenTransientFile/CloseTransientFile
Date
Msg-id 09ffc3a3-0e1d-91c6-7748-890b1829469a@joeconway.com
Whole thread Raw
In response to Tighten error control for OpenTransientFile/CloseTransientFile  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Tighten error control for OpenTransientFile/CloseTransientFile
Re: Tighten error control for OpenTransientFile/CloseTransientFile
List 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


Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Drop type "smgr"?
Next
From: Matt Pulver
Date:
Subject: Re: Infinity vs Error for division by zero