On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [...]
>> So I think the way to move this forward is to investigate how to hold
>> the SSL config constant until SIGHUP in an EXEC_BACKEND build. If we
>> find out that that's unreasonably difficult, maybe we'll decide that
>> we can live without it; but I'd like to see the question investigated
>> rather than ignored.
>
> You have a point here.
>
> In EXEC_BACKEND, parameter updated via SIGHUP are only taken into
> account by newly-started backends, right?
Oops. I mistook with PGC_BACKEND here. Sorry for the noise.
> Hence, a way to do what we
> want is to actually copy the data needed to initialize the SSL context
> into alternate file(s). When postmaster starts up, or when SIGHUP
> shows up those alternate files are upserted by the postmaster.
> be-secure-openssl.c needs also to be changed such as with EXEC_BACKEND
> the context needs to be loaded from those alternate files. At quick
> glance this seems doable.
Still, this idea would be to use a set of alternate files in global/
to set the context, basically something like
config_exec_ssl_cert_file, config_exec_ssl_key_file and
config_exec_ssl_ca_file. It does not seem to be necessary to
manipulate [read|write]_nondefault_variables() as the use of this
metadata should be made only when SSL context is initialized on
backend. Other thoughts welcome.
--
Michael
