Re: [PATCH] Reload SSL certificates on SIGHUP
От | Tom Lane |
---|---|
Тема | Re: [PATCH] Reload SSL certificates on SIGHUP |
Дата | |
Msg-id | 8917.1438133076@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] Reload SSL certificates on SIGHUP (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [PATCH] Reload SSL certificates on SIGHUP
Re: [PATCH] Reload SSL certificates on SIGHUP |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: