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,
Regards,
Nikolai
>
> Greetings,
>
> Andres Freund
>
>
