Re: libpq: Process buffered SSL read bytes to support records >8kB on async API - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: libpq: Process buffered SSL read bytes to support records >8kB on async API
Date
Msg-id CAOYmi+=isbw5OdAF8VM81yesv1bt046EadB+DO6bffHm1RpeqA@mail.gmail.com
Whole thread Raw
In response to Re: libpq: Process buffered SSL read bytes to support records >8kB on async API  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Conflict detection for update_deleted in logical replication
Next
From: Peter Geoghegan
Date:
Subject: Re: index prefetching