Re: libpq: Process buffered SSL read bytes to support records >8kB on async API

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

In response to

Browse pgsql-hackers by date

  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