Re: Nonblocking libpq + openssl = ?
От | Andres Freund |
---|---|
Тема | Re: Nonblocking libpq + openssl = ? |
Дата | |
Msg-id | 20160917002751.dkouyyveefyvbjfq@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Nonblocking libpq + openssl = ? (Nikolai Zhubr <n-a-zhubr@yandex.ru>) |
Ответы |
Re: Nonblocking libpq + openssl = ?
Re: Nonblocking libpq + openssl = ? |
Список | pgsql-general |
On 2016-09-17 03:12:53 +0300, Nikolai Zhubr wrote: > 17.09.2016 2:05, Andres Freund: > [...] > > Well, it's not pretty. I quite dislike this bit, and I've complained > > about it before. But it is noteworthy that it's nearly impossible to > > hit these days, due to ssl-renegotiation support having been ripped out. > > That's what could trigger openssl to require writes upon reads. > > 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. Greetings, Andres Freund
В списке pgsql-general по дате отправления: