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