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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Error handling (or lack of it) in RemovePgTempFilesInDir
Дата
Msg-id CAB7nPqTdmUUSu9AsrAz4fcFUFNAutw2av3EpHmRi7P7jKFf_bQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Error handling (or lack of it) in RemovePgTempFilesInDir  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: Error handling (or lack of it) in RemovePgTempFilesInDir  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: Add PGDLLIMPORT lines to some variables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Errands around AllocateDir()