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

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Lars Kanis <lars(at)greiz-reinsdorf(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com>
Subject: Re: libpq: Process buffered SSL read bytes to support records >8kB on async API
Date: 2025-07-31 21:48:08
Message-ID: CAOYmi+=YJ2J_sQ6yS8y1o9AX1Xgz35_r0hApV8QRWwi1K8gC0g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 18, 2025 at 11:11 AM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)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

Attachment Content-Type Size
v2-0001-libpq-Extend-read-pending-check-from-SSL-to-GSS.patch application/octet-stream 5.7 KB
v2-0002-libpq-Drain-all-pending-bytes-from-SSL-GSS-during.patch application/octet-stream 16.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2025-07-31 22:10:30 Re: Enable data checksums by default
Previous Message Nathan Bossart 2025-07-31 21:24:38 Re: Improve LWLock tranche name visibility across backends