| From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "Evan Martin *EXTERN*" <postgresql(at)realityexists(dot)net>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Detecting query timeouts properly |
| Date: | 2014-09-22 07:28:16 |
| Message-ID: | A737B7A37273E048B164557ADEF4A58B17D4CEFF@ntex2010i.host.magwien.gv.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Evan Martin wrote:
> I'm using PostgreSQL 9.2.8 via Npgsql 2.2.0. When a query times out it
> returns error 57014 with the message "canceling statement due to
> statement timeout". I use the message to detect the timeout and re-try
> in some cases. It seems a bit wrong to rely on the message, though - I
> presume the message text is subject to change between releases. Is there
> a better way? I cannot just rely on code 57014, because the same code is
> used when the user cancels the query (eg. from pgAdmin), in which case I
> don't want to re-try.
I don't think that there is a good way to disambiguate that, and I agree
that parsing the error message text is not a very robust solution.
Is it really necessary to bother with the case that a statement is
explicitly canceled? That should not happen too often, and if you have
statement_timeout set to non-zero, queries should not "hang" indefinitely
long anyway, right?
Yours
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xiang Gan | 2014-09-22 08:22:45 | Installing Postgresql on Linux Friendlyarm |
| Previous Message | smcg2297 | 2014-09-22 04:16:06 | Re: a couple questions about convert() |