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.
regards, tom lane
