Re: [PATCH] Reload SSL certificates on SIGHUP

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Reload SSL certificates on SIGHUP
Date: 2015-08-26 03:24:27
Message-ID: CAB7nPqSkP=n-s=EYqnKTRx5MY_KgP8JF-OLpjni+O=xAYVKBhA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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? 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.

For now I am moving the patch to the next CF, more investigation is
surely needed.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2015-08-26 03:32:55 Re: exposing pg_controldata and pg_config as functions
Previous Message Amit Kapila 2015-08-26 02:45:38 Re: Make HeapTupleSatisfiesMVCC more concurrent