| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | DGPickett <DGPickett(at)aol(dot)com> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: Subbestions: 1) Query timeout 2) Session kill by same login |
| Date: | 2009-03-13 19:31:03 |
| Message-ID: | 49BAB477.5030101@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-03-13 20:44:54 | Error in PLpgSQL with SELECT INTO and composite types |
| Previous Message | DGPickett | 2009-03-13 16:05:16 | Re: Subbestions: 1) Query timeout 2) Session kill by same login |