Re: Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has
Дата
Msg-id 9837222c0909111200g9816777nd8688f8769729c40@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Sep 11, 2009 at 10:44, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> (moving to pgsql-hackers)
>
> Tom Lane wrote:
>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>>> A completely different approach would be to treat any failure on all
>>> platforms as non-fatal. We shouldn't really cut the checkpoint short if
>>> recycling a WAL file fails, whatever the reason. That seems like a more
>>> robust approach than trying to guess which error codes are OK to ignore.
>>
>> I could live with that, as long as it gets logged.
>
> Here's a patch implementing that, and changing pgrename() to check for
> ERROR_SHARING_VIOLATION and ERROR_LOCK_VIOLATION like pgwin32_open()
> does, instead of ERROR_ACCESS_DENIED.

I have definitely seen AV programs return access deniderather than
sharing violation more than once for temporary errors. How about we
keep the access denied one as well? If we actually don't have
permissions in pg_xlog, we most likely never even got here...


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Emmanuel Cecchet
Дата:
Сообщение: Re: COPY enhancements
Следующее
От: Tom Lane
Дата:
Сообщение: Re: COPY enhancements