Обсуждение: Subbestions: 1) Query timeout 2) Session kill by same login

I do not see a features suggestion list, so here goes:

I suggest Postgres get these features:

 - Query times could be limited, by login id or class, so they error
out after N seconds.  There could even be two thresholds, one long one
for the entire query and another, shorter one for time without a row
delivered or churned.  This way, the user would not have to bother
admin, and if they did not know they had a runaway, it would take care
of itself.  If the user could institute a second, shorter limit, that
would add to the value of the feature, as the limit could be tailored
by query.  Churn in process  when timed out would be rolled back for
that query only if a transaction is in process.  The session and any
transactions would remain active.

 - A user session on one login without admin levels of permission
should be able to kill any other session on that login.  This way, the
user would not have to bother admin, and if they know they have a
runaway of a session they are no longer connected to, they can take
care of it independently and without waiting for a timeout.

For large projects, and especially when developing or where a
community of users can run their own ad-hoc or user-supplied-parameter-
limited queries, and especailly with new users/developers, excessively
long running queries are a burden to the whole team.  These features
would make Postgres and it's clones more suitable for bigger shops,
more scalable.

DGPickett wrote:
>  - Query times could be limited, by login id or class, so they error
> out after N seconds.  There could even be two thresholds, one long one
> for the entire query and another, shorter one for time without a row
> delivered or churned.  This way, the user would not have to bother
> admin, and if they did not know they had a runaway, it would take care
> of itself.  If the user could institute a second, shorter limit, that
> would add to the value of the feature, as the limit could be tailored
> by query.  Churn in process  when timed out would be rolled back for
> that query only if a transaction is in process.  The session and any
> transactions would remain active.

See statement_timeout.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Missed it, but a quock Google summary shows that it seems to apply to  admins
and so is discouraged:

_PostgreSQL: Documentation: Manuals: PostgreSQL 8.3:  Client ...._
(http://www.postgresql.org/docs/current/static/runtime-config-client.html)
Setting statement_timeout in postgresql.conf  is not recommended because it
affects all  sessions.
**************Need a job? Find employment help in your area.
(http://yellowpages.aol.com/search?query=employment_agencies&ncid=emlcntusyelp00000005)

DGPickett@aol.com wrote:
> Missed it, but a quock Google summary shows that it seems to apply to  admins
> and so is discouraged:
>
> _PostgreSQL: Documentation: Manuals: PostgreSQL 8.3:  Client ...._
> (http://www.postgresql.org/docs/current/static/runtime-config-client.html)
> Setting statement_timeout in postgresql.conf  is not recommended because it
> affects all  sessions.
> **************Need a job? Find employment help in your area.
> (http://yellowpages.aol.com/search?query=employment_agencies&ncid=emlcntusyelp00000005)

See also ALTER USER SET ...

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +