pgsql: Improve error handling in RemovePgTempFiles(). - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Improve error handling in RemovePgTempFiles().
Date
Msg-id E1eLziJ-0005Dh-PN@gemulon.postgresql.org
Whole thread Raw
Responses Re: pgsql: Improve error handling in RemovePgTempFiles().  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-committers
Improve error handling in RemovePgTempFiles().

Modify this function and its subsidiaries so that syscall failures are
reported via ereport(LOG), rather than silently ignored as before.
We don't want to throw a hard ERROR, as that would prevent database
startup, and getting rid of leftover temporary files is not important
enough for that.  On the other hand, not reporting trouble at all
seems like an odd choice not in line with current project norms,
especially since any failure here is quite unexpected.

On the same reasoning, adjust these functions' AllocateDir/ReadDir calls
so that failure to scan a directory results in LOG not ERROR.  I also
removed the previous practice of silently ignoring ENOENT failures during
directory opens --- there are some corner cases where that could happen
given a previous database crash, but that seems like a bad excuse for
ignoring a condition that isn't expected in most cases.  A LOG message
during postmaster start seems OK in such situations, and better than
no output at all.

In passing, make RemovePgTempRelationFiles' test for "is the file name
all digits" look more like the way it's done elsewhere.

Discussion: https://postgr.es/m/19907.1512402254@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/561885db05d3296082ce8750805b8ec322cf9aa1

Modified Files
--------------
src/backend/storage/file/fd.c | 70 +++++++++++++++++++++----------------------
1 file changed, 35 insertions(+), 35 deletions(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: Clean up assorted messiness around AllocateDir() usage.
Next
From: Tom Lane
Date:
Subject: pgsql: Simplify do_pg_start_backup's API by opening pg_tblspcinternall