Re: java.sql.SQLException: ERROR: canceling query due

Thanks, Oliver.

There is nothing running on the server box which would be aware of PostgreSQL other than what was installed by the PostgreSQL 8.0.3 Windows installer we downloaded. The clients are all connecting across the LAN. The failing queries terminate within a few milliseconds. Even if something was killing processes on the server, the odds that it would consistently kill processes in the small and infrequent windows of time when they are doing an update following a rollback seem vanishingly small.

I searched to ensure that nothing was invoking the Statement.setQueryTimeout method.

Since the server is Windows rather than Linux, we are doing a reboot before one final test. That seems unlikely to make a difference; but, like I said, it is Windows.

If the reboot fails to correct the problem, I really think that the pattern of failure suggests a bug where the exception / rollback / select / update (through the result set) sequence is exposing a PostgreSQL bug. Hypothetically, would such a bug most likely be strictly server-side (in which case this is the wrong forum to pursue it), or would it be likely that the JDBC driver plays some role in the problem? Would it be worth trying the V2 protocol to see if there is a change in this behavior? Any configuration setting which might affect this?

Thanks,

-Kevin


>>> Oliver Jowett <oliver(at)opencloud(dot)com> 08/17/05 6:45 PM >>>
Kevin Grittner wrote:
> The server is 8.0.3 running on Windows. The client is using the 311 build with some patches we need (from the stable branch). There is nothing we know of which would be canceling things on the server side, and nothing we know of which would be doing so on the JDBC client. (In fact, when this happens during invocation of the Connection.commit method, I don't think there is a way to cancel it programatically.)

> java.sql.SQLException: ERROR: canceling query due to user request

On a unix system I'd say that something is sending SIGINT to the backend
process. Certainly, the JDBC driver never sends a cancel request unless
you explicitly call Statement.cancel(), and as you say there's no way to
cancel a commit().

I don't know what the equivalent to sending SIGINT in the win32 world is
(there's some sort of signal emulation that the windows build uses?),
but it sounds like something on the server side rather than a JDBC issue.

-O