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 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 по дате отправления: