Re: PQConsumeinput stuck on recv

Ok, on one hand glad to hear that is an artifact, on the other hand
that means the issue is still out there...

I'm not a maintainer of Freeswitch, I am an user of it. However I am
trying to supply the maintainers with any relevant information
regarding this issue.

As you mentioned, I see the socket being modified and passed around in
the source code. Do you think the implementation is OK? I do not know
if that's standard practice when consuming libpq.

2018-03-02 17:36 GMT-03:00 Andres Freund <andres@anarazel.de>:
> 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



--

André Luis O. Freitas
System Architect

Rua do Rócio, 220 - Cj. 72
São Paulo - SP - 04552-000
55 11 4063 4222

afreitas@callix.com.br
www.callix.com.br