Yep, the pipe.c patch is unnecessary now.
Pete
>>> Bruce Momjian 05/07/06 3:44 am >>>
Now that we know the cause of the Win32 failure (FRONTEND), we don't
need the Win32 part of this patch anymore right?
---(end of broadcast)---
TIP 5: don't forge
Patch applied to HEAD, 8.1.X and 8.0.X.
---
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > It turns out the problem is that port/pipe.c is compiled with
> > > -DFRONTEND and include/port/win32.h wraps the recv to
> >
Right, and the FRONTEND fix should correct this. Sorry you had to do so
much legwork to find my mistake.
---
Peter Brant wrote:
> I'm still planning on doing this.
>
> I did add a loop around the second WSARecv in pgwin32_
Now that we know the cause of the Win32 failure (FRONTEND), we don't
need the Win32 part of this patch anymore right? (The stats display
part was already applied.)
---
Peter Brant wrote:
> Hi all,
>
> Attached are two patc
Magnus Hagander wrote:
> > It turns out the problem is that port/pipe.c is compiled with
> > -DFRONTEND and include/port/win32.h wraps the recv to
> > pgwin32_recv macro in a #ifndef FRONTEND. We've actually
> > been using the WinSock recv function directly (verified with gcc -E).
>
> That's d
I take that back. My local Postgres just didn't have stats_block_level
and stats_row_level turned on. It happens on single processor machines
too.
Pete
>>> "Peter Brant" <[EMAIL PROTECTED]> 05/02/06 6:29 pm >>>
minutes. Single processor machines don't seem to be affected.
---
As long as we have a Win32 test server around, I'm happy to help.
If you have a multi-processor development server, it's easy to recreate
though. Just load up the server (pgbench is fine) and wait a few
minutes. Single processor machines don't seem to be affected.
Pete
>>> "Magnus Hagander" <[
> It turns out the problem is that port/pipe.c is compiled with
> -DFRONTEND and include/port/win32.h wraps the recv to
> pgwin32_recv macro in a #ifndef FRONTEND. We've actually
> been using the WinSock recv function directly (verified with gcc -E).
That's definitly wrong.
Looks like this fi
It turns out the problem is that port/pipe.c is compiled with -DFRONTEND
and include/port/win32.h wraps the recv to pgwin32_recv macro in a
#ifndef FRONTEND. We've actually been using the WinSock recv function
directly (verified with gcc -E).
If somebody else could take over actually fixing this,
I'm still planning on doing this.
I did add a loop around the second WSARecv in pgwin32_recv() as that
was our best guess about where the error was coming from. As it turns
out, that's apparently not the case and I haven't had a chance to come
back to it yet.
It might be that my original patch (
Would someone generate a patch that includes all the new ideas and post
it here? Thanks.
---
Peter Brant wrote:
> Sounds good. I'll check how much we're actually looping too.
>
> Pete
>
> >>> "Magnus Hagander" <[EMAIL P
Sounds good. I'll check how much we're actually looping too.
Pete
>>> "Magnus Hagander" <[EMAIL PROTECTED]> 04/06/06 10:27 pm >>>
That's probably not a bad idea. AFAIK we haven't had reports of it
elsewhere, but it oculd happen. Want to code up a new patch, and run
some tests?
//Magnus
> --
That's probably not a bad idea. AFAIK we haven't had reports of it
elsewhere, but it oculd happen. Want to code up a new patch, and run
some tests?
//Magnus
> -Original Message-
>
> Also, do we want to move the retry loop to pgwin32_recv?
> That seems like a good idea. I'm not sure
Also, do we want to move the retry loop to pgwin32_recv? That seems
like a good idea. I'm not sure users of recv should ever have to deal
with WSAEWOULDBLOCK as it's not really an error.
Pete
>>> "Magnus Hagander" <[EMAIL PROTECTED]> 04/06/06 9:58 pm >>>
> > Attached are two patches which in co
> > Attached are two patches which in combination make pg_stat_activity
> > work reliably for us on Windows.
> > ...
> > pgstat.patch removes the delayed destroy code for backends,
> databases,
> > and tables. Database and table entries are cleaned up immediately
> > upon receipt of the approp
"Peter Brant" <[EMAIL PROTECTED]> writes:
> Attached are two patches which in combination make pg_stat_activity
> work reliably for us on Windows.
> ...
> pgstat.patch removes the delayed destroy code for backends, databases,
> and tables. Database and table entries are cleaned up immediately upon
> > BTW, what's with the change to all the error msgs?
> Ah, I'd assumed the %ui was a typo in the format string. If
> the intent was to print e.g. 10022i, I'll change it back.
Eh. No, it certainly wasn't. Keep the change :)
> > And finally, the error handling looks a bit off? We specifically
>>> "Magnus Hagander" <[EMAIL PROTECTED]> 04/06/06 7:26 pm >>>
> BTW, what's with the change to all the error msgs?
Ah, I'd assumed the %ui was a typo in the format string. If the intent
was to print e.g. 10022i, I'll change it back.
> And finally, the error handling looks a bit off? We specific
>>> On Thu, Apr 6, 2006 at 12:26 pm, in message
<[EMAIL PROTECTED]>, "Magnus
Hagander"
<[EMAIL PROTECTED]> wrote:
> And finally, the error handling looks a bit off? We specifically
*don't*
> want it to log an error for the WSAECONNRESET state - it's a normal
> state. Or am I reading the patch wro
> Oh, and checking the code go pgwin32_recv, I think I see
> where this is coming from: pgwin32_recv calls
> pgwin32_waitforsinglesocket(). If that one succeeds *and a
> signal is delivered while it's waiting*, we'll get out og
> pgwin32_waitforsinglesocket() without clearing the WSA code.
> T
> Hi all,
>
> Attached are two patches which in combination make
> pg_stat_activity work reliably for us on Windows.
>
> The mysterious socket error turned out to be WSAEWOULDBLOCK.
> Per
> http://msdn.microsoft.com/library/default.asp?url=/library/en-
> us/winsock/winsock/windows_sockets_err
21 matches
Mail list logo
