On Wed, May 10, 2006 at 05:23:29PM -0500, Jim C. Nasby wrote:
On Thu, May 11, 2006 at 12:09:32AM +0200, Martijn van Oosterhout wrote:
This stack trace doesn't make any sense. ClosePostmasterPorts is not
calling PostgresMain. And pq_getbyte is not calling TouchSocketFile,
which in
On Thu, May 11, 2006 at 12:09:56PM -0500, Jim C. Nasby wrote:
Unfortunately, I suspect some of these were grabbed after the process
had already moved past whatever was holding it in sblock.
Here's the traces that we captured...
Got 2 of these:
#0 0x00080135bd2c in recvfrom () from
On Thu, May 11, 2006 at 07:39:23PM +0200, Martijn van Oosterhout wrote:
On Thu, May 11, 2006 at 12:09:56PM -0500, Jim C. Nasby wrote:
Unfortunately, I suspect some of these were grabbed after the process
had already moved past whatever was holding it in sblock.
Here's the traces that we
On Thu, May 11, 2006 at 02:39:14PM -0500, Jim C. Nasby wrote:
On Thu, May 11, 2006 at 07:39:23PM +0200, Martijn van Oosterhout wrote:
This is an idle backend waiting for the user.
So why would that be waiting to lock the socket? My understanding is
that nothing else should be contending for
Jim C. Nasby wrote:
Yeah, my suspicion is that those processes had moved past waiting on the
socket lock by the time gdb got to them. Any idea of how you could tell
what state (as reported by top) the process was in when gdb stopped it?
I think you could send SIGSTOP to all backends at once,
On Thu, May 11, 2006 at 09:50:14PM +0200, Martijn van Oosterhout wrote:
On Thu, May 11, 2006 at 02:39:14PM -0500, Jim C. Nasby wrote:
On Thu, May 11, 2006 at 07:39:23PM +0200, Martijn van Oosterhout wrote:
This is an idle backend waiting for the user.
So why would that be waiting to
We tried reproducing this on a backup server. We haven't been able to
wedge the system into a state where there's tons of sblock processes
and nothing's getting done, but we were able to get some processes into
sblock and get stack traces:
#0 0x00080135bd2c in recvfrom () from /lib/libc.so.6
Jim C. Nasby wrote:
We tried reproducing this on a backup server. We haven't been able to
wedge the system into a state where there's tons of sblock processes
and nothing's getting done, but we were able to get some processes into
sblock and get stack traces:
#0 0x00080135bd2c in
On Wed, May 10, 2006 at 04:24:45PM -0400, Alvaro Herrera wrote:
Jim C. Nasby wrote:
We tried reproducing this on a backup server. We haven't been able to
wedge the system into a state where there's tons of sblock processes
and nothing's getting done, but we were able to get some processes
On Wed, May 10, 2006 at 04:52:38PM -0500, Jim C. Nasby wrote:
On Wed, May 10, 2006 at 04:24:45PM -0400, Alvaro Herrera wrote:
Jim C. Nasby wrote:
We tried reproducing this on a backup server. We haven't been able to
wedge the system into a state where there's tons of sblock processes
On Thu, May 11, 2006 at 12:09:32AM +0200, Martijn van Oosterhout wrote:
This stack trace doesn't make any sense. ClosePostmasterPorts is not
calling PostgresMain. And pq_getbyte is not calling TouchSocketFile,
which in turn isn't calling secure_read.
So I see... that's rather
On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
Just experienced a server that was spending over 50% of CPU time in the
system, apparently dealing with postmasters that were in the sblock
state. Looking at the FreeBSD source, this indicates
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
Actually, the stats socket seems like a really good bet to me, since all
the backends will be interested in the same socket. The
client-to-backend sockets are only touched by two processes each,
On Wed, May 03, 2006 at 01:37:03PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
Actually, the stats socket seems like a really good bet to me, since all
the backends will be interested in the same socket. The
Jim C. Nasby wrote:
On Wed, May 03, 2006 at 01:37:03PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
Actually, the stats socket seems like a really good bet to me,
since all the backends will be interested in the same
Jim C. Nasby [EMAIL PROTECTED] writes:
Just experienced a server that was spending over 50% of CPU time in the
system, apparently dealing with postmasters that were in the sblock
state. Looking at the FreeBSD source, this indicates that the process is
waiting for a lock on a socket. During
16 matches
Mail list logo
