Re: Admin nice-to-have's

Tom Lane wrote:
> 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.

Yea, added to TODO:
* Reserve last process slot for super-user if max_connections reached

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073