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-18T18:11:15Z
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
Attachments
- 0001-WIP-extend-TLS-read-pending-concept-to-GSS-too.patch (application/octet-stream) patch 0001
- 0002-WIP-add-a-drain-pending-concept-to-SSL-GSS.patch (application/octet-stream) patch 0002
On Wed, Jul 16, 2025 at 11:50 AM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > On Wed, Jul 16, 2025 at 11:11 AM Andres Freund <andres@anarazel.de> wrote: > > Do you have a WIP patch? > > I'm working on one now. The attached still needs some documentation work, and closer inspection of the new assertions and OpenSSL error handling, but I think it's good enough to get my intent across. 0001 is a fix for pqWait+gssencmode, which is hopefully the easier of the two to review/backport. The current behavior for GSS is, IMO, an obvious oversight. 0002 adds drain semantics at the end of pqReadData(). If we were writing this from scratch, it wouldn't look like this: there's no point in having the transport layer split data off into an undersized conn->inBuffer if we're just going to come right back and drain it all anyway. But I'm hoping this is easier to reason about and verify, compared to a bigger rewrite. I've renamed the existing pgtls_read_pending() to pgtls_read_is_pending(), to try to disambiguate it from the new *_drain_pending() APIs, but I'm not particularly attached to my choice of names. Thanks, --Jacob