Jason,
> > I've done some test to find where libpq hang. It does hang on the
recv
> > call of fe-misc.c line 444. When it hangs, all datas have already been
read
> > successfully on the socket, so recv should return 0 on a non blocking
> > socket?
>
> recv should return -1 with errno set to EAGAIN in nonblocking mode when
> no data is available.
OK, it does make sense. But the call to recv just block forever when all
datas are received. I suspect the problem is in cygwin (using cygwin 1.3.1-1
doens't show this problem, but there is the slow update on large fields
...).
> Did you workaround this problem by modifying the PostgreSQL code? If
> so, then please try to determine whether the problem is in Cygwin (most
> likely) or PostgreSQL. If in Cygwin, then please report it to the Cygwin
> list (cygwin@cygwin.com) with a small test case, if possible.
Yes, the workaround is a small modification of fe-misc.c to test data
availability before calling recv. I can make a report to cygwin, but I'm not
enought a sockets guru to write a small test case. Perhaps the strace output
of a session which hang at the end migh help them?
> You can find the above at:
>
>
http://members.home.net/jtishler/software/postgresql/postgresql-7.1.2-1-win3
2.tar.gz
Thanks,
This lib also have a problem with large reads, but instead of
hanging completly, an error is returned. I have eared recently some
discussion on Hacker regarding some problems with large queries with win32
libpq. Maybe it's related ?
I'm using win2000 sp2 if it matters.
cyril
