Re: [PATCH] Reload SSL certificates on SIGHUP

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Reload SSL certificates on SIGHUP
Date: 2015-07-23 05:19:46
Message-ID: CAB7nPqTxiW__tZvUcd8u42tCo=nB6a=31MgvGxEqNvRH=PmCng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson <andreas(at)proxel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2015-07-23 05:22:59 Re: pg_dump quietly ignore missing tables - is it bug?
Previous Message Robert Haas 2015-07-23 04:50:37 Re: A little RLS oversight?