Re: [PATCH] Reload SSL certificates on SIGHUP
От | Michael Paquier |
---|---|
Тема | Re: [PATCH] Reload SSL certificates on SIGHUP |
Дата | |
Msg-id | CAB7nPqTxiW__tZvUcd8u42tCo=nB6a=31MgvGxEqNvRH=PmCng@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Reload SSL certificates on SIGHUP (Andreas Karlsson <andreas@proxel.se>) |
Ответы |
Re: [PATCH] Reload SSL certificates on SIGHUP
|
Список | pgsql-hackers |
On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson <andreas@proxel.se> wrote: > On 07/02/2015 06:13 PM, Peter Eisentraut wrote: >> >> 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. > > > It is not enough to just add a hook to the GUCs since I would guess most > users would expect the certificate to be reloaded if just the file has been > replaced and no GUC was changed. Why? It seems to me that the assign hook gets called once per process at reload for a SIGHUP parameter even if its value is not changed, no? > To support this we would need to also check > the mtimes of the SSL files, would that complexity really be worth it? Or we could reload the SSL context unconditionally once per reload loop. I am wondering how costly that may prove to be though. -- Michael
В списке pgsql-hackers по дате отправления: