Re: libpq: Process buffered SSL read bytes to support records >8kB on async API
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: solai v <solai.cdac@gmail.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>,
Jacob Champion <jacob.champion@enterprisedb.com>,
Andres Freund <andres@anarazel.de>, Lars Kanis <lars@greiz-reinsdorf.de>,
pgsql-hackers@lists.postgresql.org, Merlin Moncure <mmoncure@gmail.com>
Date: 2026-07-03T09:25:10Z
Lists: pgsql-hackers
Attachments
- v4-0001-libpq-Extend-read-pending-check-from-SSL-to-GSS.patch (text/x-patch) patch v4-0001
- v4-0002-libpq-Drain-all-pending-bytes-from-SSL-GSS-during.patch (text/x-patch) patch v4-0002
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove incorrect Assert.
- 77761ee5dddc 18.0 cited