Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds

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

In response to

Responses

Browse pgsql-hackers by date

  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