>>> On 16.06.2006 at 23:21:21, in message
<[EMAIL PROTECTED]>, Bruce Momjian
wrote:
> Yea. Where you using WAL archiving? We will have a fix in 8.1.5 to
> prevent multiple archivers from starting. Perhaps that was a cause.
>
Not at the time, no. The rename in question was just a regular WAL
s
Really? If there was a patch, I missed it.
My recollection is that there was general agreement about this
particular problem (see, for example,
http://archives.postgresql.org/pgsql-bugs/2006-04/msg00189.php ), but
things kind of trailed off after that without a resolution.
As far as the complete
with
real world data and real world queries (which at least is a good
indication that it basically works).
Pete
>>> Bruce Momjian 05/11/06 4:08 am >>>
Tom Lane wrote:
> Bruce Momjian writes:
> >> Well we did have a bug report by Peter Brant, and a test by him
with
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
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 proce
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" <[
this, that would be
great. As I mentioned before, we're heading away from Windows for the
time being.
Pete
>>> Peter Brant 04/19/06 5:16 pm >>>
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
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 (
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
> --
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
>>> "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
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_error_codes_2.asp
, it se
12 matches
Mail list logo
