On 07.07.26 17:58, Heikki Linnakangas wrote:
On 03/07/2026 12:25, Heikki Linnakangas wrote:
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.
Committed and backpatched to all supported versions. Thanks everyone!
In pqDrainPending(), there is
nread = pqsecure_read(conn, conn->inBuffer + conn->inEnd,
bytes_pending);
conn->inEnd += nread;
But pqsecure_read() can return -1 for error. So adding that to
conn->inEnd at that point seems wrong.
There is error handling in the following code, but this would still kind
of corrupt the conn->inEnd value?
/* When there are bytes pending, the read function is not supposed
to fail */
if (nread != bytes_pending)
{
libpq_append_conn_error(conn,
"drained only %zu of %zd pending bytes
in transport buffer",
nread, bytes_pending);
return -1;
}
I'm not sure if that comment means that a -1 return cannot happen? Or
just that the whole error check should not happen?
Also note that the format placeholder for nread is wrong. If you do get
a -1, it will print some large unsigned value.
