Marc Munro <marc@xxxxxxxxxxxx> 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
