Re: Support for NSS as a libpq TLS backend

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <pchampion@vmware.com>, "daniel@yesql.se" <daniel@yesql.se>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "hlinnaka@iki.fi" <hlinnaka@iki.fi>, "andrew.dunstan@2ndquadrant.com" <andrew.dunstan@2ndquadrant.com>, "thomas.munro@gmail.com" <thomas.munro@gmail.com>, "andres@anarazel.de" <andres@anarazel.de>
Date: 2021-04-01T14:15:15Z
Lists: pgsql-hackers
Greetings,

* Michael Paquier (michael@paquier.xyz) wrote:
> On Wed, Mar 31, 2021 at 10:15:15PM +0000, Jacob Champion wrote:
> > I think we're going to need some analogue to PQinitOpenSSL() to help
> > client applications cut through the mess, but I'm not sure what it
> > should look like, or how we would maintain any sort of API
> > compatibility between the two flavors. And does libpq already have some
> > notion of a "main thread" that I'm missing?
> 
> Nope as far as I recall.  With OpenSSL, the initialization of the SSL
> mutex lock and the crypto callback initialization is done by the first
> thread in.

Yeah, we haven't got any such concept in libpq.  I do think that some of
this can simply be documented as "if you do this, then you need to make
sure to do this".

Thanks,

Stephen

Commits

  1. Add tab-completion for CREATE FOREIGN TABLE.

  2. Add tap tests for the schema publications.

  3. Move Perl test modules to a better namespace

  4. Adjust configure to insist on Perl version >= 5.8.3.

  5. Simplify code related to compilation of SSL and OpenSSL

  6. Introduce --with-ssl={openssl} as a configure option

  7. Implement support for bulk inserts in postgres_fdw

  8. Fix redundant error messages in client tools

  9. doc: Apply more consistently <productname> markup for OpenSSL

  10. Check ssl_in_use flag when reporting statistics