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
thereis nothing in our framework or applications that would be aware of the "set statement_timeout" command to be able
toissue 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
theulimit statements to set everything unlimited or very high, then using "su" to set user id to postgres. At that
pointthe settings from root still show. Then I'm starting postgres using pg_ctl. Is there any reason the ulimit
settingswould 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
nothinginstalled but the operating system and PostgreSQL? The only ulimit settings I couldn't set to "unlimited" were
pipesize 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 <tgl@sss.pgh.pa.us> 09/12/05 5:39 PM >>>
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> 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