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.
Of course, anyone can make an error that causes a query to run
forever, just as easily as a spelling typo! :-)
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)
Import Notes
Resolved by subject fallback
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. +