On Thu, Mar 29, 2001 at 01:00:44PM -0500, Tom Lane wrote:
> Not sure why this guy only responded to me and not the list, but here's
> a lead you might want to follow up ...
> On Thu, 29 Mar 2001 10:49:16 -0700, Scott Ribe wrote:
> > On Thu, Mar 29, 2001, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >Oh-ho, that's interesting! If you look at fe-connect.c you'll see that
> > >CONNECTION_STARTED must indicate that connect() returned EINPROGRESS
> > >rather than a success indication. The socket is supposed to go
> > >write-ready when the connection is finished...
> > Uhm, generally speaking I am not qualified to participate in this
> > discussion...
> > BUT I am pretty sure that some time past while searching for some other
> > network-related info on the MS web site I came across a document
> > describing bugs (or unique MS "features") in non-blocking IO and
> > particularly discussed the EINPROGRESS return value.
> > I don't know what I'm talking about, I could be wrong, but I think you
> > should search on the MS web site for nonblocking IO and EINPROGRESS and you
> > might find the exact info that you need to discuss with the Cygwin folks.
I quickly searched the MSDN and could not find anything explicitly
mentioning problems with non-blocking I/O and EINPROGRESS. Nevertheless,
in src/interfaces/libpq/fe-connect.c, I found the following comment:
* Since I have no idea whether this is a valid thing to do under Windows
* before a connection is made, and since I have no way of testing it, I
* leave the code looking as below. When someone decides that they want
* non-blocking connections under Windows, they can define
* WIN32_NON_BLOCKING_CONNECTIONS before compilation. If it works, then
* this code can be cleaned up.
Cygwin is essentially Windows in this regard since Cygwin uses Windows
sockets to implement Posix sockets. My WAG is that if EINPROGRESS is
returned during a connect attempt then the regression test hangs;
otherwise, the regression test runs to completion.
So, I applied the attached patch so that non-blocking I/O is not enabled
until after the connection has been established (just like with Win32
and SSL). I have the regression test running in a forever loop. So far
it has succeeded 10 times without a hang. On this machine, I have never
been able to get more than three in a row to succeed before.
I am going to run the regression tests all night. I will report back
tomorrow to let the list know whether or not I got any hangs.
Would the PostgreSQL team be willing to accept this patch? At least,
until I determine whether or not I can get Cygwin "fixed?" I will post
to the Cygwin list tomorrow (when/if they are back up).
BTW, Cygwin did not support non-blocking (socket) I/O until 1.1.5
which is in the November 2000 time frame. So another WAG is that this
problem started to occur then, but I don't really remember that well.
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com
pgsql-ports by date
|Next:||From: Thomas Lockhart||Date: 2001-03-30 06:22:21|
|Subject: Re: [PATCHES] Error in the date field (with NULL value...).Thanks!|
|Previous:||From: Alfred Perlstein||Date: 2001-03-29 19:57:30|
|Subject: Re: [ADMIN] Re: Re: [PORTS] pgmonitor and Solaris|