Test server has SP1. This bug has only bit us twice (and never in a
testing environment) so it's hard to say (from our experience).
The successful pgbench runs are definitely good to see though.
Pete
>>> "Magnus Hagander" <[EMAIL PROTECTED]> 05/02/06 10:14 am >>>
Great news. One question though
> With the patch applied, I let an inhouse stress test run for
> several hours and it completed without incident. I also ran
> two runs of pgbench with 50 connections x 1000 transactions
> and one run of 50 connections x 5000 transactions. All
> completed successfully. (Test server is a dual
With the patch applied, I let an inhouse stress test run for several
hours and it completed without incident. I also ran two runs of pgbench
with 50 connections x 1000 transactions and one run of 50 connections x
5000 transactions. All completed successfully. (Test server is a dual
Xeon with Hyp
Sure.
I should note that we're moving to Linux for our production servers so
our interest in the Windows port is waning (at least for the time
being). In particular, the stuck WAL segment rename problem has
occasionally been rather a pain in the neck.
As long as we still have Windows test server
""Peter Brant"" <[EMAIL PROTECTED]> wrote
>
> I'm afraid we're in the same category as everyone else with no good way
> to reproduce the bug, but is there anything else we could do if this
> happens again?
>
There is a "Win32 semaphore patch" in the patch list, but we are lack of
evidence to prov
Hi all,
We were bitten by this same bug over the weekend (PG 8.1.3 / Windows
Server 2003). The exact error was:
FATAL: semctl(170688872, 6, SETVAL, 0) failed: A non-blocking socket
operation could not be completed immediately.
The start of the errors corresponded to a nightly "vacuum analyze"
""Brock Peabody"" <[EMAIL PROTECTED]> wrote
>
> Do you think this is a Windows only problem?
>
I am afraid so. We have received 3 reports of this (or quite similar)
problem, all in 8.1/windows. I just noticed that yours is actually an EAGAIN
error, so the loop patch in semctl() doesn't work I gue
> On Behalf Of Tom Lane
> Perhaps you could whittle down your app into a testbed that just sends
> dummy data with about the same timing as the real app?
I think I'm starting to get a better understanding of problem. It looks
like one of the threads is trying to insert a pathological (~1,800,00
"Brock Peabody" <[EMAIL PROTECTED]> writes:
>> Can you reliablly reproduce the problem?
> I can here :). I'm trying to figure out a way for someone to repeat it
> outside my environment but I'm afraid it's got something to do with
> timing. I have 50 threads that are collecting data. If I give
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-bugs-
> [EMAIL PROTECTED] On Behalf Of Qingqing Zhou
> Sent: Wednesday, April 05, 2006 6:33 AM
> To: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #2371: database crashes with semctl failed
> error
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-bugs-
> [EMAIL PROTECTED] On Behalf Of Qingqing Zhou
> Sent: Wednesday, April 05, 2006 6:33 AM
> To: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] BUG #2371: database crashes with semctl failed
err
""Brock Peabody"" <[EMAIL PROTECTED]> wrote
>
> FATAL: semctl(167894456, 4, SETVAL, 0) failed: A non-blocking socket
> operation could not be completed immediately.
>
Can you reliablly reproduce the problem? If so, we may come up with a
testing patch to it. We encounter similar problems before b
12 matches
Mail list logo
