On Fri, 2006-08-25 at 15:43 -0400, Tom Lane wrote:
> Marc Munro <marc@bloodnok.com> writes:
> > As near as we can tell, it looks like libpq blocked inside poll inside
> > libpq_gettext.
>
> > #0 0xffffe405 in __kernel_vsyscall ()
> > #1 0x005a31d4 in poll () from /lib/tls/libc.so.6
> > #2 0xf7fd71ff in libpq_gettext () from /usr/lib/libpq.so.3
> > #3 0xf7fd7331 in pqWaitTimed () from /usr/lib/libpq.so.3
> > #4 0xf7fd73a1 in pqWait () from /usr/lib/libpq.so.3
> > #5 0xf7fd53fb in PQgetResult () from /usr/lib/libpq.so.3
> > #6 0xf7fd5524 in PQgetResult () from /usr/lib/libpq.so.3
> > #7 0x081b43b3 in SQLInterface::execute (this=3D0xf7ce3080,=20
> > cmd=3D0xf7ce0074 "execute lock_games ( '100' )") at SQLInterface.cpp:138
>
> That backtrace is silly on its face --- apparently you are using a
> stripped executable and gdb is providing the nearest global symbol
> rather than the actual function name. I think you can safely assume
> however that you are looking at libpq waiting for input from the
> backend. Does the kernel at each end still think the connection is
> live? (Try netstat) If this is a common result from short-lived
> network problems then you have a beef with the TCP stack at one end
> or the other ... TCP is supposed to be more robust than that.
Yes indeed, it is a stripped executable. We are having issues with rpms
and debug symbols and this is the best we have been able to do so far.
We will try netstat next time this happens, and we are (still) trying to
get proper debug information. More and better information will follow
when we have it.
__
Marc