> Cyril VELTER wrote:
> >> Cyril VELTER wrote:
> >>> No I'm not. It's not even complied in the server nor in the pg_dump
> > binary.
> >>> The server is built on windows using MSYS simply with ./configure &&
make
> > all
> >>> && make install
> >>>
> >>>
> >>> I've been able to reproduce the problem 6 times (at random points in
> >>> the
> >>> process, but it never complete successfully). Is there any test I can do
to
> >
> >>> help investigate the problem ?
> >> Sorry I haven't gotten back to you for a while.
> >>
> >> Yeah, if you can attach a debugger to the backend (assuming you have a
> >> predictable backend it happens to - but if you're loading, you are using
> >> a single session, I assume?), add a breakpoint around the area of the
> >> problem, and get a backtrace from exactly where it shows up, that would
> >> help.
> >
> >
> > Thanks for your reply. I'll try to do this. I've installed gdb on the
> > problematic machine and recompiled postgres with debug symbols (configure
> > --enable-debug)
> >
> > I'm not very familiar with gdb. Could you give some direction on
> > setting
the
> > breakpoint. After running gdb on the postgres.exe file, I'm not able to set
the
> > breakpoint (b socket.c:574 give me an error).
>
> Hmm, I keep forgetting that. There is some serious black magic required
> to get gdb to even approach working state on win32. I'm too used to
> working with the msvc build now. I've never actually got it working
> myself, but I know others have. Hopefully someone can speak up here? :-)
>
I don't have msvc available.
>
> > Searching the source files, it seems the error message is generated in
> > port/win32/socket.c line 594.
>
> Right, but the important thing is which path down to that function is it
> generated in. Which is why a backtrace would help.
Yes, I understand that.
>
> Looking at the code, the problem is probably somewhere in
> pgwin32_recv(). Now, it really shouldn't end up doing what you're
> seeing, but obviously it is.
After looking at the code of pgwin32_recv(), I don't understand why
pgwin32_waitforsinglesocket() is called with the FD_ACCEPT argument.
>
> Perhaps we just need to have it retry if it gets the WSAEWOULDBLOCK?
> Thoughts?
I've modified pgwin32_recv() to do that (repeat the
pgwin32_waitforsinglesocket() / WSARecv while the error is WSAEWOULDBLOCK and
not raising this error. I've an upgrade running right now (I will have the
result in the next hours).
cyril
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
