Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

* Magnus Hagander (magnus@hagander.net) wrote:
> On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane  wrote:
> > Magnus Hagander  writes:
> > > On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane  wrote:
> > >> I think probably the right thing for now is to install a do-nothing
> > >> callback, so that at least we don't have the issue of the postmaster
> > >> freezing at SIGHUP.  If someone feels like trying to revive support
> > >> of passphrase-protected server keys, that would be a perfectly fine
> > >> base to build on; they'd need a callback there anyway.
> >
> > > Does it still support passphrase protected ones on startup, or did that
> > get
> > > thrown out with the bathwater?
> >
> > It does not; what would be the point, if the key would be lost at SIGHUP?
> 
> If we lost it, yes. But we could keep the old key around if it hasn't
> changed, thus behave just like we did in <= 9.6.

Either that, or throw the same warning that we can't reload the SSL
bits if we had to ask for a passphrase at startup, again like how it
worked in 9.6.

> > > I think that's definitely a separate thing
> > > and there are a nontrivial number of people who would be interested in a
> > > setup where they can use a passphrase to protect it initially, just not
> > > reload it.
> >
> > If any of those number of people want to step up and design/implement
> > a non-broken solution for passphrases, that'd be fine with me.  But
> > I would want to see something that's actually a credible solution,
> > allowing the postmaster to be started as a normal daemon.  And working
> > on Windows.
> 
> Well, for all those people 9.6 worked significantly better... Because they
> could reload *other* config parameters without failure.

Indeed, this is important functionality that people are using.  I don't
agree with simply removing it because we want to make these options able
to be changed on a reload, that's not a good trade-off.

Thanks!

Stephen