"Venkatraju T.V." <venkatraju@xxxxxxxxx> writes: > The backtrace for the postgresql backend process at that time: > (gdb) bt > #0 0x000000321e6cc5e5 in recv () from /lib64/libc.so.6 > #1 0x00000000005004f6 in secure_read (port=0xa0e0f0, ptr=0x7dc8c0, > len=8192) at /usr/include/bits/socket2.h:35 > #2 0x0000000000506114 in pq_recvbuf () at pqcomm.c:697 > #3 0x0000000000506537 in pq_getbyte () at pqcomm.c:738 > #4 0x00000000005688b7 in PostgresMain (argc=4, argv=0x9ef7d8, > username=0x9ef7a0 "user") at postgres.c:289 This backend is waiting for input from the client; it doesn't think it's in the middle of an operation. It looks to me like this is a client-side problem, unless you want to believe that the network lost the last response sent to the client. > libpq is built with thread-safety as far as I can tell - > #define ENABLE_THREAD_SAFETY 1 > in /usr/include/pg_config_x86_64.h Thread-safety or not, libpq does not by itself provide any interlocking to make it safe for multiple threads to use the same PQconn. A multi-thread client needs to either use a separate DB connection per thread, or introduce its own mutex for a shared PQconn. If you're not doing either of those, this is probably a problem with multiple threads messing up the state of the PQconn. regards, tom lane
