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().
|
Список | 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 по дате отправления: