Re: [PATCH] Reload SSL certificates on SIGHUP

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
Date: 2015-07-02 16:13:54
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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
somewhere else.

> There was some previous discussion[1] 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.

In response to


Browse pgsql-hackers by date

  From Date Subject
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