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

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Cc: Lars Kanis <lars(at)greiz-reinsdorf(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: libpq: Process buffered SSL read bytes to support records >8kB on async API
Date: 2025-03-16 13:13:56
Message-ID: CALDaNm0_h2PdpzCddUKv7Z3k1oDg-fBXxjrENeZh7xdHYMCWkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 12 Sept 2024 at 04:30, Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> On Wed, Sep 11, 2024 at 12:08 PM Lars Kanis <lars(at)greiz-reinsdorf(dot)de> wrote:
> > How did you verify the issue on the server side - with YugabyteDB or
> > with a modified Postgres server? I'd like to verify the GSSAPI part and
> > I'm familiar with the Postgres server only.
>
> Neither, unfortunately -- I have a protocol testbed that I use for
> this kind of stuff. I'm happy to share once I get it cleaned up, but
> it's unlikely to help you in this case since I haven't implemented
> gssenc support. Patching the Postgres server itself seems like a good
> way to go.
>
> > > And are there any other sites that
> > > need to make the same guarantee before returning?
> >
> > Which other sites do you mean?
>
> I'm mostly worried that other parts of libpq might assume that a
> single call to pqReadData will drain the buffers. If not, great! --
> but I haven't had time to check all the call sites.

@Jacob, could you find some time to wrap this up? This will help us
assess whether it can be refined into a committable state soon.

Regards,
Vignesh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2025-03-16 13:16:28 Re: Adding support for SSLKEYLOGFILE in the frontend
Previous Message vignesh C 2025-03-16 13:03:07 Re: FSM doesn't recover after zeroing damaged page.