On Sun, Mar 16, 2025 at 6:14 AM vignesh C wrote:
> @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.
This is a bug report that likely requires backpatching; feature freeze
should not be an issue here.
Thanks,
--J
On Thu, 12 Sept 2024 at 04:30, Jacob Champion
wrote:
>
> On Wed, Sep 11, 2024 at 12:08 PM Lars Kanis 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 serve
On Wed, Sep 11, 2024 at 12:08 PM Lars Kanis 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 tha
Thank you Jacob for verifying this issue!
Gory details of the packet sizes, if it's helpful:
- max TLS record size is 12k, because it made the math easier
- server sends DataRow of 32006 bytes, followed by DataRow of 806
bytes, followed by CommandComplete/ReadyForQuery
- so there are three TLS r
On Sun, Sep 8, 2024 at 1:08 PM Lars Kanis wrote:
> I'm the maintainer of ruby-pg the ruby interface to the PostgreSQL
> database. This binding uses the asynchronous API of libpq by default to
> facilitate the ruby IO wait and scheduling mechanisms.
>
> This works well with the vanilla postgresql s
