Re: Nonblocking libpq + openssl = ?

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
>
>