On 07/29/2015 03:24 AM, Tom Lane wrote:
Peter Eisentraut <pete...@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
