Is it possible to get a stack trace from the stuck process?
I dunno
if you've got anything gdb-equivalent under Windows, but that's the
first thing I'd be interested in ...
Here ya go:
http://www.devisser-siderius.com/stack1.jpg
http://www.devisser-siderius.com/stack2.jpg
On Friday 10 March 2006 04:20, Magnus Hagander wrote:
Is it possible to get a stack trace from the stuck process?
I dunno
if you've got anything gdb-equivalent under Windows, but that's the
first thing I'd be interested in ...
Here ya go:
Hi,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Thursday, March 09, 2006 9:11 PM
To: Jan de Visser
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Hanging queries on dual CPU windows
Jan de Visser [EMAIL
On Friday 10 March 2006 09:03, Jan de Visser wrote:
On Friday 10 March 2006 04:20, Magnus Hagander wrote:
Is it possible to get a stack trace from the stuck process?
I dunno
if you've got anything gdb-equivalent under Windows, but that's the
first thing I'd be interested in
On Friday 10 March 2006 09:32, Jan de Visser wrote:
Actually, stack2 looks very interesting. Does it stay stuck in
pg_queue_signal? That's really not supposed to happen.
Yes it does.
An update on that: There is actually *two* processes in this state, both
hanging in pg_queue_signal.
I dunno
if you've got anything gdb-equivalent under Windows,
but that's
the first thing I'd be interested in ...
Here ya go:
http://www.devisser-siderius.com/stack1.jpg
http://www.devisser-siderius.com/stack2.jpg
On Friday 10 March 2006 10:11, Magnus Hagander wrote:
Could it be they broke it when they did that
In theory, yes, but it still seems a bit far fetched :-(
Well, I rolled back SP1 and am running my test again. Looking much better,
hasn't locked up in 45mins now, whereas before it would
Could it be they broke it when they did that
In theory, yes, but it still seems a bit far fetched :-(
Well, I rolled back SP1 and am running my test again. Looking
much better, hasn't locked up in 45mins now, whereas before
it would lock up within 5mins.
So I think they broke
On Friday 10 March 2006 13:25, Magnus Hagander wrote:
Could it be they broke it when they did that
In theory, yes, but it still seems a bit far fetched :-(
Well, I rolled back SP1 and am running my test again. Looking
much better, hasn't locked up in 45mins now, whereas before
On Friday 10 March 2006 14:27, Jan de Visser wrote:
As a BTW: I reinstalled SP1 and turned stats collection off. That also
seems to work, but is not really a solution since we want to use
autovacuuming.
I lied. I hangs now. Just takes a lot longer...
jan
--
I have more information on this issue.
First of, the problem now happens after about 1-2 hours, as opposed to the 6-8
I mentioned earlier. Yey for shorter test cycles.
Furtermore, it does not happen on Linux machines, both single CPU and dual
CPU, nor on single CPU windows machines. We can
Jan de Visser [EMAIL PROTECTED] writes:
Furtermore, it does not happen on Linux machines, both single CPU and dual
CPU, nor on single CPU windows machines. We can only reproduce on a dual CPU
windows machine, and if we take one CPU out, it does not happen.
...
Which showed me that several
On Thursday 09 March 2006 15:10, Tom Lane wrote:
Jan de Visser [EMAIL PROTECTED] writes:
Furtermore, it does not happen on Linux machines, both single CPU and
dual CPU, nor on single CPU windows machines. We can only reproduce on a
dual CPU windows machine, and if we take one CPU out, it
Is it possible to get a stack trace from the stuck process?
I dunno if you've got anything gdb-equivalent under Windows,
but that's the first thing I'd be interested in ...
Try Process Explorer from www.sysinternals.com.
//Magnus
---(end of
On Thursday 09 March 2006 15:10, Tom Lane wrote:
Is it possible to get a stack trace from the stuck process? I dunno
if you've got anything gdb-equivalent under Windows, but that's the
first thing I'd be interested in ...
Here ya go:
http://www.devisser-siderius.com/stack1.jpg
15 matches
Mail list logo
