Обсуждение: BUG #17953: Libpq can stall indefinitely with non-tls localhost (127.0.0.1) connection

The following bug has been logged on the website:

Bug reference:      17953
Logged by:          Olli Pekkola
Email address:      olli.pekkola@grundium.com
PostgreSQL version: 14.6
Operating system:   Linux
Description:

I can craft a POC if neccessary, precise steps are not super clear at this
time. But the PQexecFinish() stalled several times withtout TLS with the
following stack (with TLS, not a single instance of this is observed):

#0  0x00007fd96e33f3ff in poll () from
target:/lib/x86_64-linux-gnu/libc.so.6
#1  0x0000561c06fdbed2 in poll ()
#2  0x0000561c07664bf0 in pqSocketPoll (end_time=-1, forWrite=0, forRead=1,
sock=<optimized out>) at
src/postgresql-14.6/src/interfaces/libpq/fe-misc.c:1134
#3  pqSocketCheck (conn=conn@entry=0x619000003780, forRead=forRead@entry=1,
forWrite=forWrite@entry=0, end_time=end_time@entry=-1) at
src/interfaces/libpq/fe-misc.c:1075
#4  0x0000561c07665320 in pqWaitTimed (forRead=forRead@entry=1,
forWrite=forWrite@entry=0, conn=conn@entry=0x619000003780,
finish_time=finish_time@entry=-1)
    at src/postgresql-14.6/src/interfaces/libpq/fe-misc.c:1007
#5  0x0000561c0766536c in pqWait (forRead=forRead@entry=1,
forWrite=forWrite@entry=0, conn=conn@entry=0x619000003780) at
src/interfaces/libpq/fe-misc.c:992
#6  0x0000561c07663048 in PQgetResult (conn=0x619000003780) at
src/interfaces/libpq/fe-exec.c:2042
#7  PQgetResult (conn=0x619000003780) at src/interfaces/libpq/fe-exec.c:2007

On 01/06/2023 07:27, PG Bug reporting form wrote:
> I can craft a POC if neccessary, precise steps are not super clear at this
> time. But the PQexecFinish() stalled several times withtout TLS with the
> following stack (with TLS, not a single instance of this is observed):

Yeah, I think we'll need a self-contained repro to debug this. Or at 
least a lot more details on what the query is, what the server is doing 
when that happens, etc. A wireshark trace might be useful.

-- 
Heikki Linnakangas
Neon (https://neon.tech)

On Sat, Jun 03, 2023 at 08:36:02PM -0400, Heikki Linnakangas wrote:
> Yeah, I think we'll need a self-contained repro to debug this. Or at least a
> lot more details on what the query is, what the server is doing when that
> happens, etc. A wireshark trace might be useful.

Latency-sensitive issue perhaps?  I am unsure of what we could do here
without more evidence and/or ways to reproduce the problem.  Likely as
a small-ish libpq program and something to fake a delay?
--
Michael