Re: Connection limit doesn't work for superuser

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, x4mmm(at)yandex-team(dot)ru, efimkin(at)yandex-team(dot)ru, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Connection limit doesn't work for superuser
Date: 2018-11-07 18:14:21
Message-ID: 23533.1541614461@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> 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.

That's a fair point, and certainly if we allow and enforce "alter
user postgres nologin" (which we do), it's odd to not enforce
connection limit. However, looking at the code, it's a little
clearer why it was done that way: it's for consistency with the
behavior of datconnlimit (per-database connection limits).

I think that having superusers be immune to datconnlimit is actually
the right thing; for one reason, because datconnlimit can be set by
database owners, who should not be able to lock superusers out of
their database. If people are okay with having rolconnlimit act
differently from datconnlimit in this respect, then I'll withdraw
my objection.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-11-07 18:21:59 Re: partitioned indexes and tablespaces
Previous Message Tom Lane 2018-11-07 18:03:15 Re: file cloning in pg_upgrade and CREATE DATABASE