Re: pgwin32_open returning EINVAL - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pgwin32_open returning EINVAL
Date
Msg-id 20071219125232.GL11226@svr2.hagander.net
Whole thread Raw
In response to Re: pgwin32_open returning EINVAL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgwin32_open returning EINVAL  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Sat, Dec 15, 2007 at 10:31:38PM -0500, Tom Lane wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
> > "Andrew Dunstan" <andrew@dunslane.net> writes:
> >> Interesting. Maybe forever is going a bit too far, but retrying for <n>
> >> seconds or so.
>
> > I think looping forever is the right thing. Having a fixed timeout just means
> > Postgres will break sometimes instead of all the time. And it introduces
> > non-deterministic behaviour too.
>
> Looping forever would be considered broken by a very large fraction of
> the community.
>
> IIRC we have a 30-second timeout in rename() for Windows, and that seems
> to be working well enough, so I'd be inclined to copy the behavior for
> this case.

Here's a patch that I think implements this ;) Alvaro - do you have a build
env so you can test it? I can't reproduce the problem in my environment...

Also, it currently just silently loops. Would it be interesting to
ereport(WARNING) that it's looping on the open, to let the user know
there's a problem? (Naturally, only warning the first time it tries it on
each file, so we don't spam the log too hard)

//Magnus

Attachment

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pgwin32_open returning EINVAL
Next
From: Gregory Stark
Date:
Subject: Re: pgwin32_open returning EINVAL