One more thought on the topic -- in the particular case where we hit
this, the Statement did not have any requests active on its connection.
If the driver can determine this, it could return from the cancel method
without doing anything.
-Kevin
>>> Oliver Jowett <[EMAIL PROTECTED]> 09/13/05 6
Tom Lane wrote:
> This has been discussed before (try the pgsql-jdbc list archives).
> I believe we concluded that an appropriate fix was to not consider the
> cancel request "done" until the client sees the separate connection
> dropped by the postmaster. libpq's cancel functions wait for that t
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> The SELECT statement was easy to find, and it became clear that a
> programmer had code which was incorrectly canceling a JDBC
> Statement after reaching the end of the (empty) ResultSet. One
> time out of 1,799 this was causing the error we were seei
Thanks, Tom. An excellent suggestion. (This 50 year old dog has
today learned a new trick.)
There is good news and bad news. The good news is that I found
the cause, and we can keep this from happening with a change on
our end. The bad news is that I think it also points to a backend bug,
alt
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> I'm having a really hard time coming up with theories about the cause
> or things to check.
Have you tried strace'ing the backend process to see if you can see a
signal being delivered to it?
regards, tom lane
---
I'm having a really hard time coming up with theories about the cause
or things to check.
We ran the test again with logging to disk, and it didn't happen in an
hour of testing. The logging boosted the average run time of the
series of database modificates we attempt as a single transaction
from
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> One more thought -- I keep coming back to the fact that when we turn
> on logging in the JDBC driver on the client side, the problem does not
> occur. The only possible reason I can see for this having any affect
> on the problem is the small delay in
One more thought -- I keep coming back to the fact that when we turn on logging
in the JDBC driver on the client side, the problem does not occur. The only
possible reason I can see for this having any affect on the problem is the
small delay introduced by the synchronous logging. Since this i
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 applicatio
"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
I started with this issue on the pgsql-jdbc list, but was assured that this
could not be a bug in the JDBC driver -- it is either a bug in the
configuration or runtime environment or it is a server-side bug. This list
seemed like the logical next step.
We have seen this behavior in 8.0.3 with
(BRegards
(BIain
(B
(B- Original Message -
(BFrom: "Tom Lane" <[EMAIL PROTECTED]>
(BTo: "Iain" <[EMAIL PROTECTED]>
(BCc: <[EMAIL PROTECTED]>
(BSent: Saturday, December 20, 2003 3:11 AM
(BSubject: Re: [ADMIN] ERROR: canceling query due to u
"Iain" <[EMAIL PROTECTED]> writes:
> This is typical of the errors I got:
> pg_dump: ERROR: canceling query due to user request
If you didn't actually do anything to cancel the query, then this
indicates that something is sending SIGINT signals to the backend
process. I'd bet on a "ulimit" or eq
(B
(B
(BHi All,
(B
(BI had been having some problems since
(Byesterday with dumping/loading data and even running vacuum analyse. The good
(Bnews is that I've sorted it out and things seem to running smoothly
(Bagain.
(B
(BThere may be a bug in there somewhere, or
(Bat least a deg
14 matches
Mail list logo
