pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andreas Karlsson <andreas@proxel.se>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Reload SSL certificates on SIGHUP
Date: Wed, 29 Jul 2015 03:45:08 +0200
Message-ID: <55B83024.10804@proxel.se> (raw)
In-Reply-To: <CAB7nPqTxiW__tZvUcd8u42tCo=nB6a=31MgvGxEqNvRH=PmCng@mail.gmail.com>
References: <556A6E8A.9030400@proxel.se>
	<55956342.9050408@gmx.net>
	<55AEE95E.7090304@proxel.se>
	<CAB7nPqTxiW__tZvUcd8u42tCo=nB6a=31MgvGxEqNvRH=PmCng@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>



On 07/23/2015 07:19 AM, Michael Paquier wrote:
> On Wed, Jul 22, 2015 at 9:52 AM, Andreas Karlsson <andreas@proxel.se> wrote:
>> On 07/02/2015 06:13 PM, Peter Eisentraut wrote:
>>>
>>> I think this would be a useful feature, and the implementation looks
>>> sound.  But I don't like how the reload is organized.  Reinitializing
>>> the context in the sighup handler, aside from questions about how much
>>> work one should do in a signal handler, would cause SSL reinitialization
>>> for unrelated reloads.  We have the GUC assign hook mechanism for
>>> handling this sort of thing.  The trick would be that when multiple
>>> SSL-related settings change, you only want to do one reinitialization.
>>> You could either have the different assign hooks communicate with each
>>> other somehow, or have them set a "need SSL init" flag that is checked
>>> somewhere else.
>>
>>
>> It is not enough to just add a hook to the GUCs since I would guess most
>> users would expect the certificate to be reloaded if just the file has been
>> replaced and no GUC was changed.
>
> Why? It seems to me that the assign hook gets called once per process
> at reload for a SIGHUP parameter even if its value is not changed, no?

My bad, I tested it and you are correct. But I am not convinced moving 
the SSL initialization to a GUC assign hook would make anything clearer. 
It would not move any work out of the signal handler either since the 
assign hooks are ran inside it, and the hook will be ran in all backends 
which is not any interesting property for SSL initialization.

Andreas



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (69+ messages)  latest in thread

Message-ID: <55B83024.10804@proxel.se>
Permalink:  ../55B83024.10804@proxel.se/
Also on:    postgresql.org/message-id/55B83024.10804@proxel.se

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: andreas@proxel.se, michael.paquier@gmail.com, peter_e@gmx.net
  Subject: Re: [PATCH] Reload SSL certificates on SIGHUP
  In-Reply-To: <55B83024.10804@proxel.se>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox