Received: from localhost (maia-4.hub.org [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 859519FB4F4
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri,  6 Apr 2007 12:58:59 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 02004-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri,  6 Apr 2007 12:58:54 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from cronos.madness.at (madness.at [217.196.146.217])
	by postgresql.org (Postfix) with ESMTP id 1D1AA9FB4E3
	for <pgsql-performance@postgresql.org>;
	Fri,  6 Apr 2007 12:58:54 -0300 (ADT)
Received: from mastermind.kaltenbrunner.cc ([83.215.233.60])
	by cronos.madness.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.63) (envelope-from <stefan@kaltenbrunner.cc>)
	id 1HZqpn-00045O-Hv; Fri, 06 Apr 2007 17:58:49 +0200
Message-ID: <46166E31.3030806@kaltenbrunner.cc>
Date: Fri, 06 Apr 2007 17:58:41 +0200
From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
User-Agent: Icedove 1.5.0.9 (X11/20061220)
MIME-Version: 1.0
To: Geoffrey <esoteric@3times25.net>
CC: pgsql-performance@postgresql.org, John Allgood <john@turbocorp.com>,
	"J. D. Pearson" <jpearson@turbocorp.com>,
	Terry Lee Tucker <terry@leetuckert.net>
Subject: Re: more on high load on postgres 7.4.16
References: <46166A0D.10706@3times25.net>
In-Reply-To: <46166A0D.10706@3times25.net>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200704/167
X-Sequence-Number: 24044

Geoffrey wrote:
> We are trying to attack this problem from multiple avenues, thus I'm
> starting a separate thread.  This is with regard to the problem posted
> via thread:
> 
> http://archives.postgresql.org/pgsql-performance/2007-04/msg00120.php
> 
> One thing we are seeing with this move to the new hardware (and rhas 4)
> is database connection processes that are left over by users who have
> exited the application.  I've attached to these processes via gdb and
> find they all have the same backtrace.  Any insights into what might be
> causing this issue would be appreciated.  Understand, we did not have
> this problem on the previous hardware running on rhes 3.  Here is the
> backtrace:
> 
> #0  0x00ba47a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x0019f1de in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
> #2  0x0019ca7a in _L_mutex_lock_23 () from /lib/tls/libpthread.so.0
> #3  0xbfed9438 in ?? ()
> #4  0x00c96a4e in pthread_cond_destroy@@GLIBC_2.3.2 () from
> /lib/tls/libc.so.6
> #5  0x00c96a4e in pthread_cond_destroy@@GLIBC_2.3.2 () from
> /lib/tls/libc.so.6
> #6  0x0015243f in critSec::~critSec () from
> /usr/local/pcm170/libdalkutil.so
> #7  0x003a48b8 in Comp_ZipFiles () from /usr/local/pcm170/libcompress.so

/usr/local on RHEL should only contain software installed directly from
source - what exactly is pcm170/libdalkutil ?
beside that - is pg actually compiled with debugging symbols on that
platform ?


Stefan