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

2018-01-07 Thread Tom Lane
Thomas Munro writes: > On Mon, Jan 8, 2018 at 2:41 PM, Tom Lane wrote: >> Hearing no comments, I did it the first way. > It's funny that the two boolean arguments are always opposite. > They're essentially both saying "top level?". Yeah. I thought about using a single "bool top_level" argument

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

2018-01-07 Thread Thomas Munro
On Mon, Jan 8, 2018 at 2:41 PM, Tom Lane wrote: > I wrote: >> Hmmm ... actually, in the recursive call case, it wouldn't be that >> awful to ignore ENOENT either; if a directory goes away between being >> stat'd and being opened, you'd still get a log message about rmdir >> failure at the caller l

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

2018-01-07 Thread Tom Lane
I wrote: > Hmmm ... actually, in the recursive call case, it wouldn't be that > awful to ignore ENOENT either; if a directory goes away between being > stat'd and being opened, you'd still get a log message about rmdir > failure at the caller level. So maybe we should just do your > second alterna

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

2018-01-07 Thread Tom Lane
Thomas Munro writes: > 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 c

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

2018-01-06 Thread Tom Lane
Thomas Munro writes: > On Tue, Dec 5, 2017 at 11:59 AM, Tom Lane wrote: >> Improve error handling in RemovePgTempFiles(). > 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 table

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

2018-01-06 Thread Thomas Munro
On Tue, Dec 5, 2017 at 11:59 AM, Tom Lane 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

pgsql: Improve error handling in RemovePgTempFiles().

2017-12-04 Thread Tom Lane
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 temporar