Thread: org.postgresql.util.PSQLException: The column name x was not found in this ResultSet.
org.postgresql.util.PSQLException: The column name x was not found in this ResultSet.
From
"Kevin Grittner"
Date:
I'm pretty sure this is a bug, and it seems most likely to be in the JDBC driver, but I'm not sure.
As part of testing for a possible conversion to PostgreSQL, I ran our replication process against a converted copy of our largest database (about 200 GB). I ran in about 2 million database transactions, and I got two of these exceptions. There were multiple threads applying transactions, each with its own JDBC connection. An update is done by getting an updatable ResultSet with a SELECT * FROM "TableName" WHERE <primary key columns match literals>, using the ResultSet.updateObject(String, Object) method, based on a Map of new values, then invoking the ResultSet.updateRow method. The referenced column definitely exists in the table for which the SELECT * was run. The stack trace within the driver is pretty short:
org.postgresql.util.PSQLException: The column name isQuestReturned was not found in this ResultSet.
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.findColumn(AbstractJdbc2ResultSet.java:2381)
at org.postgresql.jdbc2.AbstractJdbc2ResultSet.updateObject(AbstractJdbc2ResultSet.java:1511)
at <my code> . . .
at java.lang.Thread.run(Thread.java:534)
For something that occurs once per million database transactions, it's hard to create a simple test case. I'm hoping someone can spot a possible cause. Given the circumstances, it looks like some race condition between the multiple JDBC threads might be involved.
The version of the JDBC driver I'm using is PostgreSQL 8.0 JDBC3 with SSL (build 311), except that on June 8th I incorporated the latest version of AbstractJdbc2ResultSet from the stable 8.0 branch, to pick up a fix I needed.
-Kevin
Kevin Grittner wrote: > > Given the circumstances, it looks like some race > condition between the multiple JDBC threads might be involved. Seems unlikely -- the JDBC driver spawns no threads itself (except for one at connection time if you specify a login timeout, but that's dead by the time the connection is established) and the objects involved in a connection should be entirely independent of objects in another connection. I wonder if there is some cross-thread access to a particular connection going on in your application. The JDBC spec says that the various exposed objects should be individually threadsafe, but I'm not sure how well we follow that. -O