From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, Michael Banck <michael(dot)banck(at)credativ(dot)de>, Peter Geoghegan <pg(at)heroku(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Reload SSL certificates on SIGHUP |
Date: | 2017-01-04 14:47:10 |
Message-ID: | 20995.1483541230@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think probably the right thing for now is to install a do-nothing
>> callback, so that at least we don't have the issue of the postmaster
>> freezing at SIGHUP. If someone feels like trying to revive support
>> of passphrase-protected server keys, that would be a perfectly fine
>> base to build on; they'd need a callback there anyway.
> Does it still support passphrase protected ones on startup, or did that get
> thrown out with the bathwater?
It does not; what would be the point, if the key would be lost at SIGHUP?
> I think that's definitely a separate thing
> and there are a nontrivial number of people who would be interested in a
> setup where they can use a passphrase to protect it initially, just not
> reload it.
If any of those number of people want to step up and design/implement
a non-broken solution for passphrases, that'd be fine with me. But
I would want to see something that's actually a credible solution,
allowing the postmaster to be started as a normal daemon. And working
on Windows.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-01-04 14:47:13 | Re: increasing the default WAL segment size |
Previous Message | Magnus Hagander | 2017-01-04 14:46:10 | Re: Replication/backup defaults |