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? :-)
> 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.
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.
Perhaps we just need to have it retry if it gets the WSAEWOULDBLOCK?
Thoughts?
//Magnus