Re: PQConsumeinput stuck on recv - Mailing list pgsql-general

From Andres Freund
Subject Re: PQConsumeinput stuck on recv
Date
Msg-id 20180302203641.vaojrm3fpzienfse@alap3.anarazel.de
Whole thread Raw
In response to Re: PQConsumeinput stuck on recv  (Andre Oliveira Freitas <afreitas@callixbrasil.com>)
Responses Re: PQConsumeinput stuck on recv  (Andre Oliveira Freitas <afreitas@callixbrasil.com>)
List pgsql-general
Hi,


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
> ../sysdeps/unix/sysv/linux/x86_64/recv.c:33
> #1  0x00007f8d26689783 in recv (__flags=0, __n=<optimized out>,
> __buf=<optimized out>, __fd=<optimized out>) at
> /usr/include/x86_64-linux-gnu/bits/socket2.h:44
> #2  pqsecure_raw_read (conn=conn@entry=0x7f8cf001e390, ptr=<optimized
> out>, len=<optimized out>) at
> /build/postgresql-10-rIfDLC/postgresql-10-10.2/build/../src/interfaces/libpq/fe-secure.c:230
> #3  0x00007f8d26689863 in pqsecure_read
> (conn=conn@entry=0x7f8cf001e390, ptr=<optimized out>, len=<optimized
> out>) at /build/postgresql-10-rIfDLC/postgresql-10-10.2/build/../src/interfaces/libpq/fe-secure.c:217
> #4  0x00007f8d266810ea in pqReadData (conn=conn@entry=0x7f8cf001e390)
> at /build/postgresql-10-rIfDLC/postgresql-10-10.2/build/../src/interfaces/libpq/fe-misc.c:683
> #5  0x00007f8d2667e6f2 in PQconsumeInput (conn=0x7f8cf001e390) at
> /build/postgresql-10-rIfDLC/postgresql-10-10.2/build/../src/interfaces/libpq/fe-exec.c:1704
> 
> 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
> execution.

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.


Greetings,

Andres Freund


pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: jsonb_array_length: ERROR: 22023: cannot get array length of ascalar
Next
From: Gary M
Date:
Subject: Re: Is there a continuous backup for pg ?