Re: libpq: Process buffered SSL read bytes to support records >8kB on async API
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Lars Kanis <lars@greiz-reinsdorf.de>, pgsql-hackers@lists.postgresql.org
Date: 2025-03-16T13:13:56Z
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
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