From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Gurjeet Singh <gurjeet(at)singh(dot)im>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds |
Date: | 2022-05-26 21:40:14 |
Message-ID: | 2458121.1653601214@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I think you're overreacting to a behavior that isn't really very surprising.
> If we don't initialize SSL the first time, we don't have a working SSL
> stack. If we didn't choose to die at that point, we'd be starting up a
> server that could not accept any SSL connections. I don't think users
> would like that.
> If we don't *reinitialize* it, we *do* have a working SSL stack. We
> haven't been able to load the updated configuration, but we still have
> the old one. We could fall over and die anyway, but I don't think
> users would like that either. People don't expect 'pg_ctl reload' to
> kill off a working server, even if the new configuration is bad.
The larger context here is that this is (or at least is supposed to be)
exactly the same as our reaction to any other misconfiguration: die if
it's detected at server start, but if it's detected during a later SIGHUP
reload, soldier on with the known-good previous settings. I believe
that's fairly well documented already.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2022-05-26 21:45:50 | Re: Assert name/short_desc to prevent SHOW ALL segfault |
Previous Message | Greg Hennessy | 2022-05-26 21:39:19 | Re: selectivity function |