On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson <andr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
