From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Lars Kanis <lars(at)greiz-reinsdorf(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: libpq: Process buffered SSL read bytes to support records >8kB on async API |
Date: | 2024-09-11 23:00:25 |
Message-ID: | CAOYmi+nmT+VRMKnyfLmW0FQh3Qynz_Aw4V=4FqK7=oz=b8m_BQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> > I need to switch away from this for a bit. Would you mind adding this
> > to the next Commitfest as a placeholder?
>
> No problem; registered: https://commitfest.postgresql.org/50/5251/
Thank you!
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-09-11 23:07:31 | Re: query_id, pg_stat_activity, extended query protocol |
Previous Message | Jacob Champion | 2024-09-11 22:54:18 | Re: [PoC] Federated Authn/z with OAUTHBEARER |