Neil Conway [EMAIL PROTECTED] 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
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] 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
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
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
A couple of admin nice-to-have's based on the last few weeks of 24x7
operation are:
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.
Log
Scott Shattuck [EMAIL PROTECTED] 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
Neil Conway wrote:
Scott Shattuck [EMAIL PROTECTED] 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
