Re: pgsql: Break out OpenSSL-specific code to separate files.

On 08/17/2014 03:15 PM, Andres Freund wrote:
> On 2014-08-11 09:11:08 +0000, Heikki Linnakangas wrote:
>> Break out OpenSSL-specific code to separate files.
>>
>> This refactoring is in preparation for adding support for other SSL
>> implementations, with no user-visible effects. There are now two #defines,
>> USE_OPENSSL which is defined when building with OpenSSL, and USE_SSL which
>> is defined when building with any SSL implementation. Currently, OpenSSL is
>> the only implementation so the two #defines go together, but USE_SSL is
>> supposed to be used for implementation-independent code.
>>
>> The libpq SSL code is changed to use a custom BIO, which does all the raw
>> I/O, like we've been doing in the backend for a long time. That makes it
>> possible to use MSG_NOSIGNAL to block SIGPIPE when using SSL, which avoids
>> a couple of syscall for each send(). Probably doesn't make much performance
>> difference in practice - the SSL encryption is expensive enough to mask the
>> effect - but it was a natural result of this refactoring.
>>
>> Based on a patch by Martijn van Oosterhout from 2006. Briefly reviewed by
>> Alvaro Herrera, Andreas Karlsson, Jeff Janes.
>
> Any reason for the odd ordering of be_tls_write() in
> be-secure-openssl.c? It's:
>
> ssize_t be_tls_write(Port *port, void *ptr, size_t len)
> ...
> /* ------------------------------------------------------------ */
> /*      OpenSSL specific code                                   */
> /* -----------------------git------------------------------------- */
> ...
> static int
> my_sock_read(BIO *h, char *buf, int size)
> ...
> static int
> my_sock_write(BIO *h, const char *buf, int size)
> ...
> ...
> ssize_t
> be_tls_read(Port *port, void *ptr, size_t len)
>
> That doesn't really seem to make sense to me.

No, you're right. It grew out that way from the original order of the
functions in be-secure.c, but it doesn't make sense as it is. I have now
moved all the public interface functions to the top and the static
functions to the bottom.

- Heikki