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

From Magnus Hagander
Subject Re: Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has
Date
Msg-id 9837222c0909111200g9816777nd8688f8769729c40@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has
List 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 by date:

Previous
From: Emmanuel Cecchet
Date:
Subject: Re: COPY enhancements
Next
From: Tom Lane
Date:
Subject: Re: COPY enhancements