On Fri, Jul 18, 2025 at 12:55 PM Andres Freund wrote:
>
> Hi,
I think we're talking past each other, so let me try to focus on just
a few items here. I'm happy to go back and respond point-by-point if
needed.
> I don't know your fix really looks like - afaict you haven't shared it. So
> it's har
Hi,
On 2025-07-17 09:48:29 -0700, Jacob Champion wrote:
> On Wed, Jul 16, 2025 at 4:35 PM Andres Freund wrote:
> > Why do we care about not hitting the socket? We always operate the socket in
> > non-blocking mode anyway?
>
> IIUC, that would change pqReadData() from a bounded read to an
> unbou
On Fri, Jul 18, 2025 at 11:11 AM Jacob Champion
wrote:
> The current behavior for GSS is, IMO, an
> obvious oversight.
(A better way to word this would have been "clearly an oversight"; I
didn't mean to imply that the correct behavior is obvious. The
opposite, in fact.)
--Jacob
On Wed, Jul 16, 2025 at 11:50 AM Jacob Champion
wrote:
> On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote:
> > Do you have a WIP patch?
>
> I'm working on one now.
The attached still needs some documentation work, and closer
inspection of the new assertions and OpenSSL error handling, but I
On Wed, Jul 16, 2025 at 4:35 PM Andres Freund wrote:
> Why do we care about not hitting the socket? We always operate the socket in
> non-blocking mode anyway?
IIUC, that would change pqReadData() from a bounded read to an
unbounded one. Then we have to somehow protect against a server that
can s
Hi,
On 2025-07-16 15:25:14 -0700, Jacob Champion wrote:
> On Wed, Jul 16, 2025 at 2:34 PM Andres Freund wrote:
> > > Based on my understanding of [1], readahead makes this overall problem
> > > much worse by opportunistically slurping bytes off the wire and doing
> > > absolutely nothing with the
On Wed, Jul 16, 2025 at 2:34 PM Andres Freund wrote:
> > Based on my understanding of [1], readahead makes this overall problem
> > much worse by opportunistically slurping bytes off the wire and doing
> > absolutely nothing with them until you call SSL_read() enough times to
> > finally get to th
Hi,
On 2025-07-16 11:50:46 -0700, Jacob Champion wrote:
> On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote:
> > If one modifies libpq to use openssl readahead (which does result in
> > speedups,
> > because otherwise openssl think it's useful to do lots of 5 byte reads from
> > the socket),
On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote:
> If one modifies libpq to use openssl readahead (which does result in speedups,
> because otherwise openssl think it's useful to do lots of 5 byte reads from
> the socket), I see occasional hangs in libpq.
Now that is a very interesting coinc
On Wed, Jul 16, 2025 at 7:36 AM Merlin Moncure wrote:
> Agreed. Here's a little more detail on the case I noticed:
>
> * postgres backend thread managing several libpq connections, with polling
> is_busy loop
> * when client pushed a lot of log messages (say, with 'RAISE NOTICE'), the
> server w
Hi,
On 2025-07-15 15:31:25 -0700, Jacob Champion wrote:
> So I think pqReadData() needs to make the same guarantees for SSL/GSS
> that it does for plain TCP: when it returns, either 1) there are no
> bytes left pending or 2) the socket itself is marked readable.
> Otherwise I think we'll continue
On Tue, Jul 15, 2025 at 4:31 PM Jacob Champion <
jacob.champ...@enterprisedb.com> wrote
> Otherwise I think we'll continue to chase weird corner cases.
>
Agreed. Here's a little more detail on the case I noticed:
* postgres backend thread managing several libpq connections, with polling
is_busy
On Wed, Jul 2, 2025 at 4:12 PM Jacob Champion
wrote:
> I'll work on proving that code paths other than PQconsumeInput() are
> affected. If they are, I'll start a patch for pqReadData().
Here's one way for a server implementation to hang the client during
PQconnectPoll(): accept the SSLRequest and
On Sun, Sep 8, 2024 at 2:08 PM Lars Kanis wrote:
> To fix this issue the attached patch calls pqReadData() repeatedly in
> PQconsumeInput() until there is no buffered SSL data left to be read.
> Another solution could be to process buffered SSL read bytes in
> PQisBusy() instead of PQconsumeInput
On Tue, Jul 1, 2025 at 1:42 PM Jacob Champion
wrote:
> I do
> not yet understand why this protection is not extended to
> GSS-encrypted connections.
After repurposing some of my test code for d98cefe11, I'm able to
reproduce the hang with gssencmode when the server uses a
smaller-than-standard (1
On Tue, Sep 10, 2024 at 11:49 AM Jacob Champion
wrote:
> I need to switch away from this for a bit.
"a bit"
In an effort to get this unstuck (and ideally solved during this
commitfest) here are my most recent thoughts:
> I agree that PQconsumeInput() needs to ensure that the transport
> buffers
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
737561270
From ab793829a4ce473f1cc2bbc0e2a6f6753553255d Mon Sep 17 00:00:00 2001
From: Lars Kanis
Date: Sun, 8 Sep 2024 13:59:05 +0200
Subject: [PATCH] libpq: Process buffered SSL read bytes to support records
>8kB on async API
The async API of libpq doesn't support SSL record sizes >8kB so far.
This size isn't
22 matches
Mail list logo
