Re: Support for NSS as a libpq TLS backend - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id YFqHmspKASMHcH7V@paquier.xyz
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
Responses Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
On Wed, Mar 24, 2021 at 12:05:35AM +0000, Jacob Champion wrote:
> The first database loaded by NSS_InitContext() becomes the "default"
> database. This is what I'm currently hung up on. I can't figure out how
> to get NSS to use the database that was loaded for the current
> connection, so in my local patches for the issues above, client
> certificates fail to load. I can work around it temporarily for the
> tests, but this will be a problem if any libpq clients load up multiple
> independent databases for use with separate connections. Anyone know if
> this is a supported use case for NSS?

Are you referring to the case of threading here?  This should be a
supported case, as threads created by an application through libpq
could perfectly use completely different connection strings.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Support for NSS as a libpq TLS backend
Next
From: Tomas Vondra
Date:
Subject: Re: PoC/WIP: Extended statistics on expressions