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

Jacob Champion <jacob.champion@enterprisedb.com>

From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Lars Kanis <lars@greiz-reinsdorf.de>, pgsql-hackers@lists.postgresql.org, Merlin Moncure <mmoncure@gmail.com>
Date: 2025-07-18T21:30:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove incorrect Assert.

On Fri, Jul 18, 2025 at 12:55 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,

I think we're talking past each other, so let me try to focus on just
a few items here. I'm happy to go back and respond point-by-point if
needed.

> I don't know your fix really looks like - afaict you haven't shared it. So
> it's hard to actually comment with specifics to it.

Just upthread [1]. Emails probably crossed while you were typing.

> I am not saying that a to-be-backpatched-fix needs to make openssl readahead
> work, that'd be absurd. But I am concerned with more fundamentally entrenching
> the idea that there never is any buffering below libpq's buffering, it'll
> cause trouble down the line.

And I'm not saying that I'm fundamentally opposed to a future
architecture that allows readahead. But I do want to pin behavior
that's required for safety in the _current_ architecture. We can unpin
it if the order of operations is changed; assertions that have been
added can always be deleted.

> FWIW, I don't care about what we do during connection establishment.

I have to care, because upthread I've shown that we can deadlock there
too. My goal in this thread is to fix the deadlock generally, on all
branches.

--Jacob

[1] https://postgr.es/m/CAOYmi%2BmD6EbDEYfwZON0FCUAvGO%2B2%3DjR2V4KQYx%2Bd%2Bg0ap0Amg%40mail.gmail.com