Skip site navigation (1) Skip section navigation (2)

Re: pgwin32_open returning EINVAL

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>,Andrew Dunstan <andrew(at)dunslane(dot)net>,Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>,Martijn van Oosterhout <kleptog(at)svana(dot)org>,Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgwin32_open returning EINVAL
Date: 2007-12-19 12:52:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Dec 15, 2007 at 10:31:38PM -0500, Tom Lane wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> > "Andrew Dunstan" <andrew(at)dunslane(dot)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)


In response to


pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-12-19 13:05:00
Subject: Re: pgwin32_open returning EINVAL
Previous:From: Magnus HaganderDate: 2007-12-19 12:45:20
Subject: Re: pgwin32_open returning EINVAL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group