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

From Jacob Champion
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id 5fcd199604f5e533e0e5a29ecdcfe6f93049b6bd.camel@vmware.com
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
On Tue, 2022-01-25 at 22:26 +0000, Jacob Champion wrote:
> On Wed, 2022-01-19 at 10:01 +0100, Daniel Gustafsson wrote:
> > > On 18 Jan 2022, at 17:37, Jacob Champion <pchampion@vmware.com> wrote:
> > > 
> > > On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
> > > > I've attached a v50 which fixes the issues found by Joshua upthread, as well as
> > > > rebases on top of all the recent SSL and pgcrypto changes.
> > > 
> > > I'm currently tracking down a slot leak. When opening and closing large
> > > numbers of NSS databases, at some point we appear to run out of slots
> > > and then NSS starts misbehaving, even though we've closed all of our
> > > context handles.
> > 
> > Interesting, are you able to share a reproducer for this so I can assist in
> > debugging it?
> 
> (This was in my spam folder, sorry for the delay...) Let me see if I
> can minimize my current reproduction case and get it ported out of
> Python.

Here's my attempt at a Bash port. It has races but reliably reproduces
on my machine after 98 connections (there's a hardcoded slot limit of
100, so that makes sense when factoring in the internal NSS slots).

--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BRIN summarization vs. WAL logging
Next
From: Tomas Vondra
Date:
Subject: Re: Bug in ProcArrayApplyRecoveryInfo for snapshots crossing 4B, breaking replicas