Re: pgsql: Improve error handling in RemovePgTempFiles(). - Mailing list pgsql-committers

From Thomas Munro
Subject Re: pgsql: Improve error handling in RemovePgTempFiles().
Date
Msg-id CAEepm=2cSkY_MkirVbGRpAaxL5GDfS+W6N0GjTADCuZsKjtTLg@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Improve error handling in RemovePgTempFiles().  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Improve error handling in RemovePgTempFiles().
List pgsql-committers
On Mon, Jan 8, 2018 at 2:41 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 level.  So maybe we should just do your
>> second alternative as-is (ie, code as above but without missing_ok).
>> Having an explicit control parameter seems marginally clearer but
>> I'm not sure it's buying anything meaningful.  Thoughts?
>
> 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?".  I was also a bit
confused about who else would delete the file in between the check and
the attempt to open it with my proposal, considering this is code
running in the postmaster at startup, so I figured I must be missing
something and hadn't got around to figure out what and replying.
Thanks for fixing this.

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


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Improve error handling in RemovePgTempFiles().
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Improve error handling in RemovePgTempFiles().