Re: PQConsumeinput stuck on recv

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andre Oliveira Freitas <afreitas(at)callixbrasil(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: PQConsumeinput stuck on recv
Date: 2018-03-02 20:36:41
Message-ID: 20180302203641.vaojrm3fpzienfse@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)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(at)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(at)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(at)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gary M 2018-03-02 20:44:52 Re: Is there a continuous backup for pg ?
Previous Message Adrian Klaver 2018-03-02 20:26:18 Re: jsonb_array_length: ERROR: 22023: cannot get array length of a scalar