Message-ID: <55B82208.4090901@gmx.net>
Date: Tue, 28 Jul 2015 20:44:56 -0400
From: Peter Eisentraut <peter_e@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Andreas Karlsson <andreas@proxel.se>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Reload SSL certificates on SIGHUP
References: <556A6E8A.9030400@proxel.se> <55956342.9050408@gmx.net>
 <55AEE95E.7090304@proxel.se>
In-Reply-To: <55AEE95E.7090304@proxel.se>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 7/21/15 8:52 PM, Andreas Karlsson wrote:
> 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?

Actually, I misread your patch.  I thought you only wanted to reload the
SSL files when the GUC settings change, but of course we also want to
reload them when the files are changed.

I don't have a problem with rebuilding the SSL context on every reload
cycle.  We already do a lot of extra reloading every time, so a bit more
shouldn't hurt.  But I'm not so sure whether we should do that in the
SIGHUP handler.  I don't know how we got into the situation of doing all
the file reloads directly in the handler, but at least we can control
that code.  Making a bunch of calls into an external library is a
different thing, though.  Can we find a way to do this differently?


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