Re: Nonblocking libpq + openssl = ? - Mailing list pgsql-general

From Andres Freund
Subject Re: Nonblocking libpq + openssl = ?
Date
Msg-id 20160917002751.dkouyyveefyvbjfq@alap3.anarazel.de
Whole thread Raw
In response to Re: Nonblocking libpq + openssl = ?  (Nikolai Zhubr <n-a-zhubr@yandex.ru>)
Responses Re: Nonblocking libpq + openssl = ?  (Nikolai Zhubr <n-a-zhubr@yandex.ru>)
Re: Nonblocking libpq + openssl = ?  (Nikolai Zhubr <n-a-zhubr@yandex.ru>)
List 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 by date:

Previous
From: Nikolai Zhubr
Date:
Subject: Re: Nonblocking libpq + openssl = ?
Next
From: Nikolai Zhubr
Date:
Subject: Re: Nonblocking libpq + openssl = ?