Re: [PATCH] Reload SSL certificates on SIGHUP
От | Peter Eisentraut |
---|---|
Тема | Re: [PATCH] Reload SSL certificates on SIGHUP |
Дата | |
Msg-id | 55956342.9050408@gmx.net обсуждение исходный текст |
Ответ на | [PATCH] Reload SSL certificates on SIGHUP (Andreas Karlsson <andreas@proxel.se>) |
Ответы |
Re: [PATCH] Reload SSL certificates on SIGHUP
|
Список | 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.
В списке pgsql-hackers по дате отправления: