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
