17.09.2016 3:27, Andres Freund:
Looks like it _usually_ happens so that such interdependent reads and writes
are unnecessary in the absence of renegotiations. But still [1] instructs to
always check for both SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE in all
cases. Supposedly it is for a reason. The way it is implemented in
fe-secure-openssl.c looks just somewhat unfinished.
I'm wondering is there really something that prevents doing it properly?

The relevant user-level API of libpq (PQisBusy) doesn't have a way to
return "waiting for write". So we'd have to break API compatibility.

Ah, I see. But then, this is a very common sort of problem (Existing API spec getting inadequate for some new features added later, maintaining complete interface compatability getting impossible.)

In this specific case, I'd say a reasonable approach would be to urgently introduce some new PQisBusyParams() returning the flag in question, and subsequently deprecating the historical PQisBusy(). Maybe something else would be necessary. Meanwhile, it would seem logical to move this busy-loop to PQisBusy() so it would become more evident PQisBusy() is flawed.

Besides, even with no changes to API, one good thing can be done still.
If SSL_ERROR_WANT_WRITE is so unlikely to ever happen in pgtls_read(), why not just throw a (descriptive enough) error and get out immediately? And see if someone compains about dropped connections because of this?

And while we are at it, it would be nice to have something like pqWaitTimed() included in the API, so as to be able to (mostly) avoid messing with the underlying OS handles/sockets outside of libpq (and keeping user code more generic therefore). Is there a reason for not providing this?

Thank you,


Andres Freund

Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:

Reply via email to