Re: Error handling (or lack of it) in RemovePgTempFilesInDir

2017-12-04 Thread Tom Lane
Michael Paquier writes: > On Tue, Dec 5, 2017 at 11:15 AM, Tom Lane wrote: >> The general theory I'm operating on is that we should endeavor to >> let the database start in any situation where that doesn't involve >> a data-corruption hazard. Yeah, it might not be nice if we leave >> GB worth of

Re: Error handling (or lack of it) in RemovePgTempFilesInDir

2017-12-04 Thread Michael Paquier
On Tue, Dec 5, 2017 at 11:15 AM, Tom Lane wrote: > Michael Paquier writes: >> On Tue, Dec 5, 2017 at 10:51 AM, Tom Lane wrote: >>> Uh ... I'm confused? That particular change only concerns whether we emit >>> a log message, not whether the action is attempted or succeeds. > >> From the commit m

Re: Error handling (or lack of it) in RemovePgTempFilesInDir

2017-12-04 Thread Tom Lane
Michael Paquier writes: > On Tue, Dec 5, 2017 at 10:51 AM, Tom Lane wrote: >> Uh ... I'm confused? That particular change only concerns whether we emit >> a log message, not whether the action is attempted or succeeds. > From the commit mentioned upthread, this switches one hard failure > when

Re: Error handling (or lack of it) in RemovePgTempFilesInDir

2017-12-04 Thread Michael Paquier
On Tue, Dec 5, 2017 at 10:51 AM, Tom Lane wrote: > Michael Paquier writes: >> On Tue, Dec 5, 2017 at 8:40 AM, Thomas Munro >> wrote: >>> Belatedly, +1. The error hiding seemed a bit odd considering that we >>> were prepared to log "unexpected file found ...". I probably should >>> have questio

Re: Error handling (or lack of it) in RemovePgTempFilesInDir

2017-12-04 Thread Tom Lane
Michael Paquier writes: > On Tue, Dec 5, 2017 at 8:40 AM, Thomas Munro > wrote: >> Belatedly, +1. The error hiding seemed a bit odd considering that we >> were prepared to log "unexpected file found ...". I probably should >> have questioned that instead of extending it monkey-see-monkey-do. >

Re: Error handling (or lack of it) in RemovePgTempFilesInDir

2017-12-04 Thread Michael Paquier
On Tue, Dec 5, 2017 at 8:40 AM, Thomas Munro wrote: > On Tue, Dec 5, 2017 at 4:44 AM, Tom Lane wrote: >> Anyway, I'm inclined to reverse that choice and emit LOG messages >> reporting failure of any of the lstat, rmdir, or unlink calls in >> RemovePgTempFilesInDir. In the worst case, say that th

Re: Error handling (or lack of it) in RemovePgTempFilesInDir

2017-12-04 Thread Thomas Munro
On Tue, Dec 5, 2017 at 4:44 AM, Tom Lane wrote: > Anyway, I'm inclined to reverse that choice and emit LOG messages > reporting failure of any of the lstat, rmdir, or unlink calls in > RemovePgTempFilesInDir. In the worst case, say that there are a > bunch of leftover temp files in a directory th

Error handling (or lack of it) in RemovePgTempFilesInDir

2017-12-04 Thread Tom Lane
The recent changes in commit dc6c4c9dc caused Coverity to start complaining that RemovePgTempFilesInDir calls rmdir() without checking its return value, as would be good practice. Now, this wasn't really a fault of that commit, because the code was already ignoring the result of unlink(), but it d