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: | 2025-07-02 23:12:40 |
Message-ID: | CAOYmi+=kbb7pV7k7RfWUcFt=CArJmp1R+R1Xnb8UnZLwpFgOwA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 1, 2025 at 1:42 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> 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 (12k) send buffer. Same reproduction case as the
original (32006-byte DataRow, 806-byte DataRow, CommandComplete,
ReadyForQuery).
So a complete patch for this has to consider GSS as well.
> So, to fix this once and for all, do we have to make sure that
> pqReadData() always fully drains the SSL/GSS transport buffer instead
> of eagerly returning?
I'll work on proving that code paths other than PQconsumeInput() are
affected. If they are, I'll start a patch for pqReadData().
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-07-02 23:14:32 | Re: Persist injection points across server restarts |
Previous Message | Michael Paquier | 2025-07-02 22:57:42 | Re: libpq OpenSSL and multithreading |