"Venkatraju T.V." <venkatraju@gmail.com> 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
