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 →
-
Remove incorrect Assert.
- 77761ee5dddc 18.0 cited
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