Skip site navigation (1) Skip section navigation (2)

Re: ERROR: canceling query due to user request

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: ERROR: canceling query due to user request
Date: 2005-09-13 13:51:29
Message-ID: s326931e.001@gwmta.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-admin
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 <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 IngenDate: 2005-09-13 14:47:37
Subject: Re: Server Time Setting
Previous:From: Marcin GiedzDate: 2005-09-13 12:31:16
Subject: Re: plperl again but different problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group