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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds
Дата
Msg-id 2458121.1653601214@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Patch: Don't set LoadedSSL unless secure_initialize succeeds  (Gurjeet Singh <gurjeet@singh.im>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Hennessy
Дата:
Сообщение: Re: selectivity function
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: Assert name/short_desc to prevent SHOW ALL segfault