On Wed, Jul 29, 2015 at 10:24 AM, Tom Lane <tgl@sss.pgh.pa.us> 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?
There are no numbers on this thread. And honestly I would be curious
as well to see a run of pgbench with -C doing or similar to check how
long it takes to establish a connection. I would expect it to be
measurable though, but here I'm just hand-waving ;)
> 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.
Indeed.
--
Michael