|From:||Peter Eisentraut <peter_e(at)gmx(dot)net>|
|To:||Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [PATCH] Reload SSL certificates on SIGHUP|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 5/30/15 10:14 PM, Andreas Karlsson wrote:
> I have written a patch which makes it possible to change SSL
> certificates (and other SSL parameters, including the CRL) without
> restarting PostgreSQL. In fact this patch also makes it possible to turn
> on or off ssl entirely without restart. It does so by initializing a new
> SSL context when the postmaster receives a SIGHUP, and if the
> initialization succeeded the old context is replaced by the new.
I think this would be a useful feature, and the implementation looks
sound. But I don't like how the reload is organized. Reinitializing
the context in the sighup handler, aside from questions about how much
work one should do in a signal handler, would cause SSL reinitialization
for unrelated reloads. We have the GUC assign hook mechanism for
handling this sort of thing. The trick would be that when multiple
SSL-related settings change, you only want to do one reinitialization.
You could either have the different assign hooks communicate with each
other somehow, or have them set a "need SSL init" flag that is checked
> There was some previous discussion on the mailing list about what the
> proper context should be for the SSL parameters, but as far as I can
> tell the discussion never reached a conclusion. I have changed the SSL
> GUCs to PGC_SIGUP since I felt that was the closest to the truth, but it
> is not a perfect fit (the backends wont reload the SSL context). Should
> we add a new context for the SSL GUCs?
I think PGC_SIGHUP is fine for this.
|Next Message||Heikki Linnakangas||2015-07-02 16:22:51||Re: Fix autoconf deprecation warnings|
|Previous Message||Tom Lane||2015-07-02 16:10:15||Re: Raising our compiler requirements for 9.6|