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