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?
>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 09/12/05 5:39 PM >>>
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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
pgsql-admin by date
|Next:||From: Lane Van Ingen||Date: 2005-09-13 14:47:37|
|Subject: Re: Server Time Setting |
|Previous:||From: Marcin Giedz||Date: 2005-09-13 12:31:16|
|Subject: Re: plperl again but different problem|