Thanks, Tom.
The statement_timeout setting was also raised on the JDBC list, and has been
checked -- there is nothing setting statement_timeout. The connection shows
this value at zero. None of our code contains anything PostgreSQL specific, so
there is nothing in our framework or applications that would be aware of the
"set statement_timeout" command to be able to issue it. I created the database
instance, the user and the database, and have not set this as a default
anywhere.
Regarding the possibility that a ulimit setting is sending the signal, I am
using "su" to set user id to root, issuing the ulimit statements to set
everything unlimited or very high, then using "su" to set user id to postgres.
At that point the settings from root still show. Then I'm starting postgres
using pg_ctl. Is there any reason the ulimit settings would not carry through
with this approach? Is there a better way to do it?
Other than that, what external causes might be at fault when I have both
Windows machines and Linux machines which have nothing installed but the
operating system and PostgreSQL? The only ulimit settings I couldn't set to
"unlimited" were pipe size and open files. Is there any chance that the
error/rollback path in the code is leaking open files on the server? Is there
anything I should run during the test to watch for potential resource
exhaustion?
-Kevin
>>> Tom Lane <[EMAIL PROTECTED]> 09/12/05 5:39 PM >>>
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> org.postgresql.util.PSQLException: ERROR: canceling query due to user request
The only possible trigger of that message is a SIGINT sent to the backend.
Now the backend will SIGINT itself if a statement timeout expires, so one
possibility is that you have statement_timeout set and it's getting
exceeded. Otherwise you need to be looking for external causes.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
