Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Lars Kanis <lars(at)greiz-reinsdorf(dot)de>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: libpq: Process buffered SSL read bytes to support records >8kB on async API
Date: 2025-07-03 01:19:08
Message-ID: CAHyXU0w1qUzxmXPa30FBNFu+wjLOCvU0N6ezuE0XK+eWWEugTQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Sep 8, 2024 at 2:08 PM Lars Kanis <lars(at)greiz-reinsdorf(dot)de> wrote:

> To fix this issue the attached patch calls pqReadData() repeatedly in
> PQconsumeInput() until there is no buffered SSL data left to be read.
> Another solution could be to process buffered SSL read bytes in
> PQisBusy() instead of PQconsumeInput() .
>

I've definitely seen this problem in AWS RDS, or something related to
this. I'm using dblink to set up lots of connections and using
dblink_is_busy (which calls PQconsumeInput). If there is lots of data
being returned, say, with large results or log information, the server
would stall for unknown reasons (sometimes for several seconds or more)
while peeling off the 8kb fragments. Point being, PQconsumeInput() not
draining the buffers can lead to major performance problems that are hard
to troubleshoot. I would argue this a bug, really.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-07-03 01:30:29 RE: A assert failure when initdb with track_commit_timestamp=on
Previous Message Masahiko Sawada 2025-07-03 01:16:57 Re: Inconsistent LSN format in pg_waldump output