Re: libpq: Process buffered SSL read bytes to support records >8kB on async API
От | vignesh C |
---|---|
Тема | Re: libpq: Process buffered SSL read bytes to support records >8kB on async API |
Дата | |
Msg-id | CALDaNm0_h2PdpzCddUKv7Z3k1oDg-fBXxjrENeZh7xdHYMCWkA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: libpq: Process buffered SSL read bytes to support records >8kB on async API (Jacob Champion <jacob.champion@enterprisedb.com>) |
Ответы |
Re: libpq: Process buffered SSL read bytes to support records >8kB on async API
|
Список | pgsql-hackers |
On Thu, 12 Sept 2024 at 04:30, Jacob Champion <jacob.champion@enterprisedb.com> wrote: > > On Wed, Sep 11, 2024 at 12:08 PM Lars Kanis <lars@greiz-reinsdorf.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
В списке pgsql-hackers по дате отправления: