Re: Error handling (or lack of it) in RemovePgTempFilesInDir - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Error handling (or lack of it) in RemovePgTempFilesInDir
Date
Msg-id CAB7nPqTdmUUSu9AsrAz4fcFUFNAutw2av3EpHmRi7P7jKFf_bQ@mail.gmail.com
Whole thread Raw
In response to Re: Error handling (or lack of it) in RemovePgTempFilesInDir  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Error handling (or lack of it) in RemovePgTempFilesInDir
List pgsql-hackers
On Tue, Dec 5, 2017 at 8:40 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Tue, Dec 5, 2017 at 4:44 AM, Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Add PGDLLIMPORT lines to some variables
Next
From: Tom Lane
Date:
Subject: Re: Errands around AllocateDir()