From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
Cc: | Scott Shattuck <ss(at)technicalpursuit(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Admin nice-to-have's |
Date: | 2002-08-16 04:55:08 |
Message-ID: | 200208160455.g7G4t8r15334@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway wrote:
> Scott Shattuck <ss(at)technicalpursuit(dot)com> writes:
> > Allow DBA/Database Owner to log in even when max_connections has
> > been reached so they can determine which queries are hung via
> > pg_stat_activity etc. and perform any other needed work to restore
> > stability.
>
> Allowing the database owner to login seems definately wrong: it's not
> unusual for many of the normal database clients to run as the owner of
> the database they operate on. So this would effectively disable the
> max_connections limit in this situation.
>
> 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).
You would have to do it the unix kernel way when the PROC structure
fills; it keeps the last slot open and only lets root use it. If this
is desirable, I can add it to TODO.
--
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 05:05:07 | Open 7.3 items, with names |
Previous Message | Bruce Momjian | 2002-08-16 04:51:26 | Re: [HACKERS] Better handling of parse errors |