On 2018-03-01 19:20:04 -0300, Andre Oliveira Freitas wrote:
> I was able to capture the backtrace again, now with libpq debugging symbols.
> Thread 15 (Thread 0x7f8cec068700 (LWP 68)):
> #0 0x00007f8d252a1d9b in __libc_recv (fd=150, buf=0x7f8cf0034410,
> n=16384, flags=623517083, flags@entry=0) at
> #1 0x00007f8d26689783 in recv (__flags=0, __n=<optimized out>,
> __buf=<optimized out>, __fd=<optimized out>) at
> #2 pqsecure_raw_read (conn=conn@entry=0x7f8cf001e390, ptr=<optimized
> out>, len=<optimized out>) at
> #3 0x00007f8d26689863 in pqsecure_read
> (conn=conn@entry=0x7f8cf001e390, ptr=<optimized out>, len=<optimized
> out>) at
> #4 0x00007f8d266810ea in pqReadData (conn=conn@entry=0x7f8cf001e390)
> #5 0x00007f8d2667e6f2 in PQconsumeInput (conn=0x7f8cf001e390) at
> In this case, I also checked the pg_stat_activity and this particular
> connection on pg server side was idle for 15 minutes. I killed it
> using pg_terminate_backend, and then somehow the application resumed
There's something decidedly weird going on. Libpq always keeps the
connection in nonblocking mode internally. Blocking is implemented by
using select on the socket. So this should never block.
Is there any chance parts of your application changes the sockets
block-y-ness? Is see your code is passing the socket around, so perhaps
that's happening somewhere outside of the file?
> As you can see, recv has received a non-zero value in flags
Well, no, not really. recv() has a 0 flags, it's just libc's internal
implementation that appears to be showing up weird afaict.