Re: [HACKERS] error handling in RegisterBackgroundWorker

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] error handling in RegisterBackgroundWorker
Дата
Msg-id CAKFQuwZckEaXwTcN_5g=1iBM1yMtHKy8opnjk+J89egP2GBvOw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] error handling in RegisterBackgroundWorker  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] error handling in RegisterBackgroundWorker
Список pgsql-hackers
On Tue, Apr 11, 2017 at 11:10 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 4/11/17 11:47, David G. Johnston wrote:
> ​A potential middle-ground is to start, but then only allow superuser
> connections.

Then you might as well start and allow all connections.  I don't see
what this buys.


​If "leave it offline until it gets fixed" is on the table then there is some underlying reason that we'd not want application (or replication) users connecting to the database while it is in a degraded state.  Even if one accepts that premise that doesn't mean that an administrator shouldn't be allowed to login and do ad-hoc stuff; the goal of the prevention is to disallow programmed external actors that assume/require that these background worker processes are active from connecting while they are not.  This middle-ground accommodates that goal​ in a precise manner.

I don't have an opinion as to which extreme is better so in the absence I'm in favor of "put control in the hands of the administrator" - this just provides a slightly more usable environment for the administrator to operate within.

David J.

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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] Variable substitution in psql backtick expansion
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Why does logical replication launcher set application_name?