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

On 14/05/2026 07:32, solai v wrote:
> Hi,
> i tested the latest V3 patch series on current postgreSQL HEAD with SSL
> enabled.The patches applied cleanly,build succeeded,and the server
> started successfully.I ran the async libpq test repeatedly and also
> tested large COPY TO STDOUT operations over SSL.I did not observe
> hangs,crashes,or visible regressions during testing.

Thanks for the testing!

Here's another patch version, with some small comment and commit message
changes, and I split the changes slightly differently between the two
patches. End result is otherwise the same.

I plan to commit this in the next few days.

This question still remains:

> In pqReadData we have this:
>
>
>> /*
>> * A return value of 0 could mean just that no data is now available, or
>> * it could mean EOF --- that is, the server has closed the connection.
>> * Since we have the socket in nonblock mode, the only way to tell the
>> * difference is to see if select() is saying that the file is ready.
>> * Grumble. Fortunately, we don't expect this path to be taken much,
>> * since in normal practice we should not be trying to read data unless
>> * the file selected for reading already.
>> *
>> * In SSL mode it's even worse: SSL_read() could say WANT_READ and then
>> * data could arrive before we make the pqReadReady() test, but the second
>> * SSL_read() could still say WANT_READ because the data received was not
>> * a complete SSL record. So we must play dumb and assume there is more
>> * data, relying on the SSL layer to detect true EOF.
>> */
>>
>> #ifdef USE_SSL
>> if (conn->ssl_in_use)
>> return 0;
>> #endif
>
>
> Should we do the same for GSS as we do for SSL here?

If someone more familiar with GSS would take a look at that, that'd be
great. I assume that it has the same issue, and we should do the same
for GSS as for SSL here. That's additional to these patches, though, so
it doesn't prevent committing these now.

- Heikki