From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, Scott Shattuck <ss(at)technicalpursuit(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Admin nice-to-have's |
Date: | 2002-08-16 15:12:40 |
Message-ID: | 200208161512.g7GFCeQ19361@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Neil Conway <nconway(at)klamath(dot)dyndns(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-08-16 15:20:34 | Re: Open 7.3 items, with names |
Previous Message | Larry Rosenman | 2002-08-16 15:09:46 | Re: Open 7.3 items |