[Re] Re: [Re] Re: [Re] Re: Winsock error 10035 while trying to upgrade from 8.0 to 8.2

["Cyril VELTER" <cyril(dot)velter(at)metadys(dot)com>]

> 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