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

On Tue, Dec 5, 2017 at 8:40 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Tue, Dec 5, 2017 at 4:44 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 that someone has made
>> unwritable, this might cause a fair amount of whining in the postmaster
>> log --- but that's a situation that needs to be fixed anyway, so
>> I cannot see how not printing anything is a good idea.
>
> 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.

Well, I am -1 on this change. The coding before commit 561885d that
you have now pushed (timezone makes me answer later) was way more
conservative and I honestly preferred it as *only* the next postmaster
restart would remove remnant temp files which can cause potentially GB
of data to stay around. Also, if the failure happens at startup, isn't
it going to fail as well for backends afterwards? This would cause
backends to fail abruptly and it is actually easier to debug a
completely stopped instance...
--
Michael