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-31T21:48:08Z
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
- v2-0001-libpq-Extend-read-pending-check-from-SSL-to-GSS.patch (application/octet-stream) patch v2-0001
- v2-0002-libpq-Drain-all-pending-bytes-from-SSL-GSS-during.patch (application/octet-stream) patch v2-0002
On Fri, Jul 18, 2025 at 11:11 AM Jacob Champion <jacob.champion@enterprisedb.com> wrote: > The attached still needs some documentation work v2 does a bunch of commit message work, but I imagine it needs a good bit of copy-editing for clarity. I'm not in any hurry to smash this in. I think we still need - independent verification of the architectural issue, to make sure it's not any deeper or shallower than pqReadData() - independent verification that this fixes the bugs that have been described - measurement of the performance characteristics of the new code - verification of the maximum amount of additional buffer memory that can be consumed during the drain - consensus that we want to maintain this new behavior - discussion of what we want this code to look like going forward Andres, does this patch help clarify my thoughts upthread? Ideally the additional code isn't getting in the way of any future rearchitectures, since it only pins the new requirement in the code that needs it. Thanks, --Jacob