Message-ID: <55AEE95E.7090304@proxel.se>
Date: Wed, 22 Jul 2015 02:52:46 +0200
From: Andreas Karlsson <andreas@proxel.se>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Reload SSL certificates on SIGHUP
References: <556A6E8A.9030400@proxel.se> <55956342.9050408@gmx.net>
In-Reply-To: <55956342.9050408@gmx.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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. To support this we would need to 
also check the mtimes of the SSL files, would that complexity really be 
worth it?

Andreas


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers