Message-ID: <55BAA50E.5040908@proxel.se>
Date: Fri, 31 Jul 2015 00:28:30 +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: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>
CC: 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> <55B82208.4090901@gmx.net>
 <8917.1438133076@sss.pgh.pa.us>
In-Reply-To: <8917.1438133076@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 07/29/2015 03:24 AM, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> 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?
>
> Do we have an idea how expensive it is to load that data?
>
> A brute-force answer is to not have the postmaster load it at all,
> but to have new backends do so (if needed) during their connection
> acceptance/authentication phase.  I'm not sure how much that would
> add to the SSL connection startup time though.  It would also mean
> that problems with the SSL config files would only be reported during
> subsequent connection starts, not at SIGHUP time, and indeed that
> SIGHUP is more or less meaningless for SSL file changes: the instant
> you change a file, it's live for later connections.  On the plus side,
> it would make Windows and Unix behavior closer, since (I suppose)
> we're reloading that stuff anyway in EXEC_BACKEND builds.

I measured it taking ~0.3ms to build the new SSL context in a simple 
benchmark (certificate + CA + small crl).

Personally I do not think moving this to connection start would be worth 
it since reporting errors that late is not nice for people who have 
misconfigured their database, and even if my benchmarks indicates it is 
relatively cheap to reload SSL adding more work to connection 
establishing is something I would want to avoid unless it gives us a 
clear benefit.

> I'm not entirely sure your concern is valid, though.  We have always had
> the principle that almost everything of interest in the postmaster happens
> in signal handler functions.  We could possibly change things so that
> reloading config files is done in the "main loop" of ServerLoop, but
> if we did, it would have to execute with all signals blocked, which seems
> like just about as much of a risk for third-party code as executing that
 > code in a signal handler is.

Agreed, I am not sure what moving it to the main loop would gain us.

-- 
Andreas


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