Re: [HACKERS] error handling in RegisterBackgroundWorker - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: [HACKERS] error handling in RegisterBackgroundWorker
Date
Msg-id CAKFQuwZckEaXwTcN_5g=1iBM1yMtHKy8opnjk+J89egP2GBvOw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] error handling in RegisterBackgroundWorker  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] error handling in RegisterBackgroundWorker  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] Variable substitution in psql backtick expansion
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Why does logical replication launcher set application_name?