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'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.
regards, tom lane