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

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: pgsql: Improve error handling in RemovePgTempFiles().
Дата
Msg-id CAEepm=2cSkY_MkirVbGRpAaxL5GDfS+W6N0GjTADCuZsKjtTLg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql: Improve error handling in RemovePgTempFiles().  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pgsql: Improve error handling in RemovePgTempFiles().  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Improve error handling in RemovePgTempFiles().
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Improve error handling in RemovePgTempFiles().