On Wed, Jul 29, 2015 at 10:24 AM, Tom Lane <t...@sss.pgh.pa.us> 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?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers