On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
