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
?
The problem is solved (but I'm sure that it isn't the right solution)
with doing the recv call only if pqReadReady is true (else we set nread to
0).
BTW, does somebody know where I can find a recent native win32 libpq.dll
binarie (the ones I find on the WEB have also some problems with large
datas) ? For my client side program, I would prefer to have the native libpq
to avoid deploying cygwin on all clients.
cyril
> > On Sat, Aug 18, 2001 at 06:51:53PM +0200, Cyril VELTER wrote:
> > > I've done some more tests and the problem seem libpq related (and
> not
> > > backend related). In fact, if I use the windows psql to connect to a
> linux
> > > server, I get the exact same problem. When I use linux psql with
either
> > > linux or cygwin backend all is fine.
> >
> > Does "windows psql" imply Cygwin or Win32 psql? If Cygwin, can you
> > repeat with the Win32 psql? Also, please try to use strace to figure
> > out what is going on under Cygwin:
>
> it's cygwin psql (by oppostion to linux one). I've no access to a VC++
> compiler so I have no native win32 psql. But meantime I've tried my
> application with zde libpq.dll. The beavior is not the same : the datas
> which caused cygwin libpq to Hang are returned truncated ...
>
