On Wed, Nov 7, 2018 at 9:22 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Nov 7, 2018 at 11:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I'm not buying the argument that there are realistic use-cases where
> > you need a connection limit on a superuser role, either. Whatever
> > you're doing that might merit a connection limit should not be done
> > as superuser. I think this proposal boils down to asking for support
> > for an incredibly bad application design, and equipping every database
> > with an additional foot-gun in order to have that.
>
> I don't agree; that sounds like masterminding to me. "You shouldn't
> want that feature, so we won't give it to you" is not always an
> invalid argument, but we ought to tread lightly with it.
On the reject side changing reasonable behavior based upon a single
complaint is somewhat over-reactive.
On the accept side, which I'm leaning toward, is that superuser is
already constrained by max_connections and, in addition, the
implications of setting this value are straight-forward and it obvious
requires intent on the part of the user. Its not a "foot-gun" in the
sense that there are side-effects that the user isn't going to be
aware of by having this feature in place - it does exactly what the
label says it does. POLA says it should either apply to the superuser
or the attempt to set the value to anything but -1 should fail. I say
changing it so the feature actually works is the correct course of
action.
Maybe it should be impossible to set the value to zero while we are in
there. Document setting "NOLOGIN" as the way to prevent a user from
making connections.
Having a validation on the role table that at least one superuser must
have login privileges might be good too if you are interested in
putting some protections in place to avoid self-inflicted lockouts.
But it doesn't seem to be a big issue.
David J.
