Re: pgsql: Improve error handling in RemovePgTempFiles().

On Tue, Dec 5, 2017 at 11:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Improve error handling in RemovePgTempFiles().
>
> [...] 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.

Was it intentional that a newly created cluster produces a LOG error
on startup until you eventually do something to cause base/pgsql_tmp
to exist? Same for each tablespace you create.

2018-01-07 16:34:20.352 NZDT [77400] LOG: could not open directory
"base/pgsql_tmp": No such file or directory
2018-01-07 16:34:20.354 NZDT [77400] LOG: could not open directory
"pg_tblspc/16384/PG_11_201712251/pgsql_tmp": No such file or directory

Perhaps RemovePgTempFiles() could check if each one exists before
calling RemovePgTempFilesInDir(), like in the attached? Alternatively
we could make RemovePgTempFilesInDir() return early if temp_dir ==
NULL (going against your commit message above), or I suppose we could
arrange for temporary directories always to exist in base and each
tablespace.

--
Thomas Munro
http://www.enterprisedb.com