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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
