Re: Admin nice-to-have's - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Admin nice-to-have's
Date
Msg-id 7027.1029504926@sss.pgh.pa.us
Whole thread Raw
In response to Re: Admin nice-to-have's  (Neil Conway <nconway@klamath.dyndns.org>)
Responses Re: Admin nice-to-have's  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Neil Conway <nconway@klamath.dyndns.org> writes:
> I don't see a major problem with allowing postgres to login if the
> connection limit is hit (although I'm not sure it's worth the worry,
> when 'kill a backend executing SELECT ; psql template1 postgres' works
> as-is).

max_connections is a hard limit; you do not have the option of letting
people in anyway, because there'll be no PROC slot for them.

We could consider establishing a "soft" connection limit that's somewhat
less than max_connections, and allowing non-superusers to log in only
if the soft limit hasn't been exceeded.  This does not guarantee that
superusers can always get in: the extra slots might have been filled by
other superuser connections.  But it'd give them better odds than the
rabble.

I tend to concur with Neil that the usefulness of such a feature is
dubious.  But OTOH such a practice has always existed for Unix disk
space --- maybe we should respect that precedent.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: where to put NO_MKTIME_BEFORE_1970?
Next
From: Tom Lane
Date:
Subject: Re: Open 7.3 items