Merlin Moncure wrote:
> On 10/28/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> On Thu, 2006-10-26 at 11:06 -0400, Merlin Moncure wrote:
>> > On 10/26/06, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
>> > > This is pretty interesting - where can I read more on this?
>> Windows isn't
>> > > actually h
>
> Yes, this issue comes up often - I wonder if the Woodcrest Xeons
resolved
> this? Have these problems been experienced on both Linux and Windows
(we
> are
> running Windows 2003 x64)
>
> Carlo
>
IIRC Woodcrest doesn't have HT, just dual core with shared cache.
- Bucky
-
On 10/28/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Thu, 2006-10-26 at 11:06 -0400, Merlin Moncure wrote:
> On 10/26/06, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> > This is pretty interesting - where can I read more on this? Windows isn't
> > actually hanging, one single command line windo
> I do think we need some better instrumentation for this kind of thing.
Well, one thing's for sure - I have little other information to offer. The
problem is that the lockups occur after hours of operation and thousands of
rows being digested (which is the nature of the program). If "better
in
>Ben Trewern" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
> It might be worth turning off hyperthreading if your Xeons are using it.
> There have been reports of this causing inconsistent behaviour with
> PostgreSQL.
Yes, this issue comes up often - I wonder if the Woodcrest Xe
On Thu, 2006-10-26 at 11:06 -0400, Merlin Moncure wrote:
> On 10/26/06, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
> > This is pretty interesting - where can I read more on this? Windows isn't
> > actually hanging, one single command line window is - from its behaviour, it
> > looks like the TCL p
> Perl has a wealth of modules on CPAN to do almost anything you need to.
> TCL has the beginning of one (not as rich), but comes built-in with things
> like event loops, and graphicals (Tk).
>
> I could go on and on - but I won't, because this is the PostgreSQL
> mailing list. People either get
Perl started out fast - TCL started out slow. Perl used syntax that,
although it would drive some people crazy, followed a linguistic curve
that Larry Wall claimed was healthy. The English language is crazy,
and yet, it has become standard world wide as well. Designed, regular
languages like Espera
> when it happens, make sure to query pg_locks and see what is going on
> there lock issues are not supposed to manifest on a commit, which
> releases locks, but you never know.
There aren't any pedning locks (assuming that pgAdmin is using pg_locks to
display pendin glocks).
> There have been r
On Thu, 26 Oct 2006, Carlo Stonebanks wrote:
>
> It could even be that there's something wrong with the TCL package, but from
> my understanding it is one of the most complete interfaces out there - which
> is weird, because TCL seems to be the most unpopular language in the
> community.
>
Not t
> A context switch storm is when your machine spends more time trying to
> figure out what to do than actually doing anything. The CPU spends most
> it's time switching between programs than running them.
Well, we usually use the term "thrashing" as the generic for when your
machine is spending
On 10/26/06, Carlo Stonebanks <[EMAIL PROTECTED]> wrote:
This is pretty interesting - where can I read more on this? Windows isn't
actually hanging, one single command line window is - from its behaviour, it
looks like the TCL postgresql package is waiting for pg_exec to come back
from the commit
This is pretty interesting - where can I read more on this? Windows isn't
actually hanging, one single command line window is - from its behaviour, it
looks like the TCL postgresql package is waiting for pg_exec to come back
from the commit (I believe the commit has actually gone through).
It c
> I can just see the postgresql group getting together at the next
> O'Reilley's conference and creating that band. And it will all be your
> fault.
Finally, a chance for me to wear my black leather pants.
> A context switch storm is when your machine spends more time trying to
> figure out what
I seem to remember Oleg/Teodor recently reporting a problem with Windows
hanging on a multi-processor machine, during a heavy load operation.
In their case it seemed like a vacuum would allow it to wake up. They
did commit a patch that did not make it into the last minor version for
lack of testi
> > > You may try to figure out what's the process doing (the backend
> > > obviously, not the frontend (Tcl) process) by attaching
> to it with
> > > strace.
> >
> > It's so sad when us poor Windows guys get helpful hints from people
> > assume that we're smart enough to run *NIX... ;-)
>
>
On Wed, Oct 25, 2006 at 04:32:16PM -0400, Carlo Stonebanks wrote:
> >> I have a question for you: did you have a long running query keeping open
> a transaction? I've just noticed the same problem here, but things cleaned
> up immediately when I aborted the long-running transaction.
>
> No, the o
>
>>> Maybe it's swamped by a context switch storm (but in that case, probably
>>> the other processes would be affected as well).
>> What is a context switch storm? (and what a great name for a heavy metal
>> rock band!)
>
> I can just see the postgresql group getting together at the next
> O'
On Wed, 2006-10-25 at 15:07, Carlo Stonebanks wrote:
> > You may try to figure out what's the process doing (the backend
> > obviously, not the frontend (Tcl) process) by attaching to it with
> > strace.
>
> It's so sad when us poor Windows guys get helpful hints from people assume
> that we're s
Carlo Stonebanks wrote:
You may try to figure out what's the process doing (the backend
obviously, not the frontend (Tcl) process) by attaching to it with
strace.
It's so sad when us poor Windows guys get helpful hints from people assume
that we're smart enough to run *NIX..
>> I have a question
for you: did you have a long running query keeping open a transaction?
I've just noticed the same problem here, but things cleaned up immediately when
I aborted the long-running transaction.
No, the only processes are from those in
the import applications themselves
> You may try to figure out what's the process doing (the backend
> obviously, not the frontend (Tcl) process) by attaching to it with
> strace.
It's so sad when us poor Windows guys get helpful hints from people assume
that we're smart enough to run *NIX... ;-)
> Maybe it's swamped by a context
Carlo Stonebanks wrote:
> The delays are so long that I used to think the app was hopelessly frozen.
> By accident, I left the app alone in its frozen state and came back a good
> deal later and seen that it was running again.
>
> Sometimes I decide it *IS* frozen and have to restart. Because C
23 matches
Mail list logo