From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chris Campbell <ccampbell(at)cascadeds(dot)com> |
Cc: | "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: Time-Out Issue |
Date: | 2014-01-08 20:01:30 |
Message-ID: | 15189.1389211290@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Chris Campbell <ccampbell(at)cascadeds(dot)com> writes:
> In PostgreSQL 9.3.2, is there a default time-out for running processes (specifically a view via a data connection) that take a long time?
No. There is the statement_timeout parameter, but it's not enabled by
default; and anyway if you were hitting a statement timeout you'd be
getting a pretty specific error message, like this:
ERROR: canceling statement due to statement timeout
If so, how do I bump it up? My data connection (Devart) keeps returning time-out errors from PostgreSQL for views that must filter and return massive datasets. Smaller datasets it has no problem with.
Why do you say the error is "from PostgreSQL"? It seems rather more
likely that this is some kind of client-side timeout.
If the query requires a great deal of server think-time before it sends
any rows, it's possible that you are hitting a network connection timeout.
NAT routers in particular often drop "idle" connections after a few
minutes. That breaks all sorts of RFC rules, but they do it anyway.
You can usually work around network issues by setting aggressive TCP
keepalive parameters, either at the server or client end, to keep some
traffic flowing on the network link.
I don't know what Devart is, but another possibility is that it has got
some idea of a query timeout.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Campbell | 2014-01-08 20:23:52 | Re: Time-Out Issue |
Previous Message | Chris Campbell | 2014-01-08 19:47:41 | Re: Time-Out Issue |