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 the 311 JDBC driver. Today I tested with the latest snapshot of the 8.1 development code and the tip of the JDBC driver code from the root. It still happens.
The environment for the latest test is:
SuSE Linux 9.3 (i586)
2.6.11.4-21.8-smp #1 SMP Tue Jul 19 12:42:37 UTC 2005
Dual Xeon
Disk on 7 spindle RAID 5 via SAN
All access through JDBC connections.
A single thread accessing the database.
A connection pool in use -- the thread may grab a different connection each time.
No other process concurrently executing against the database.
Happens with or without autovacuum running.
Failures have also occured on Windows 2000 and Windows XP servers with local hard drives. Xeons in all cases.
The software involved "optimistically" tries to do a series of inserts, updates, and/or deletes in a single database transaction. If an exception occurs (for example an insert of a row which already exists) or an update affects zero rows, the transaction is rolled back and the operations are attempted in "cautious" mode -- a commit after each insert update or delete of a single row.
The client is running full out, with a steady supply of ready-to-go requests. Client CPU seems to be the bottleneck, rather than anything on the database server hardware. We are only seeing this problem in "cautious" mode -- a database transaction has been rolled back and we're committing each statement as we go.
If we run the same set of data multiple times, the error occurs on different requests each time, indicating it is not data dependent. If we turn on logging at the JDBC driver level, it never happens, indicating that it is timing sensitive. We've never seen it while stepping through the debugger, but since it seems to happen randomly once every few thousand requests, that would be a unlikely anyway.
The error is manifest by this message and stack trace:
org.postgresql.util.PSQLException: ERROR: canceling query due to user request
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1499)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1284)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:175)
at org.postgresql.jdbc2.AbstractJdbc2Connection.executeTransactionCommand(AbstractJdbc2Connection.java:617)
at org.postgresql.jdbc2.AbstractJdbc2Connection.commit(AbstractJdbc2Connection.java:637)
at (our application code)
There is no method in the JDBC interface to cancel a commit from the client side, and there is nothing in the client code which is trying to do so. There are no processes running on the server except services from the SuSE install and the processes started by pg_ctl start.
We tried setting the ulimit of everything to unlimited, where allowed. We set the open files limit to 4096. These ulimit changes had no affect on the problem.
Does anyone have any ideas on a possible cause, or any diagnostic steps we should take?
Thanks,
-Kevin