Re: Possible bug / regression from generated keys - Mailing list pgsql-jdbc
From | Dave Cramer |
---|---|
Subject | Re: Possible bug / regression from generated keys |
Date | |
Msg-id | CADK3HHK60GdVAo-DDe8bbEhHJt==4_ZUbnvvWG-XLxY5EBZyXQ@mail.gmail.com Whole thread Raw |
In response to | Re: Possible bug / regression from generated keys (dmp <danap@ttc-cmc.net>) |
Responses |
Re: Possible bug / regression from generated keys
|
List | pgsql-jdbc |
Peter,
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
Is this easily replicated, or does it only happen once in a while ?
Dave
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Wed, Nov 7, 2012 at 12:21 PM, dmp <danap@ttc-cmc.net> wrote:
Sorry i did not post the first reply to the mailing list, but did
now. I would say see wait and see if someone else replies or search
the list for change.
Of hand I would say Bigserial Type java.lang.Long int8 should not
have been caught by that routine. From the Field class that column
is being tied to Binary Data.
Field Class
//The V3 protocol defines two constants for the format of data
public static final int TEXT_FORMAT = 0;
public static final int BINARY_FORMAT = 1;
By the way the ByteConverter was created by:
Helper methods to parse java base types from byte arrays.
*
* @author Mikko Tiihonen
danap.
Peter Cooner wrote:Thanks dmp -
Ah! Forgot to include the column information -
I added code to the function call which is reading the ResultSet
object, and output the column name and type info, so the column is
declared:
position_id bigint default nextval('track_position_sequence'),
And according to JDBC says "bigserial position_id" which I believe is correct?
On Wed, Nov 7, 2012 at 11:44 AM, dmp<danap@ttc-cmc.net> wrote:I don't think a mountain of data is required for this one.
The ByteConverter class does not exist for the 9.1-902 so
was introduced later and is in 9.2-100X. Since git holds
no history I can not determine introduction, but a search
of this mailing list would perhaps lead to the reason for
the change.
What I can say is it looks like the column is binary. I
could compile the source for 9.2-1001 with output that
may tell you perhaps more information. I suspect though
someone here is more familiar with the change to understand
the problem. I would say this behavior is undesirable and
could be classified as a bug.
danap.
Peter Cooner wrote:
Summary:
I'm getting an exception from the ResultSet returned from
getGeneratedKey() from a batch insert PreparedStatement. When I use
any of the postgresql-9.2-100X.jdbc4.jar drivers I get exceptions, but
when I use postgresql-9.1-902.jdbc4.jar it works.
Has anyone seen anything like this? How can I debug this problem
further? How should I go about determining if this is a bug?
Exception:
java.lang.ArrayIndexOutOfBoundsException: 4
at org.postgresql.util.ByteConverter.int8(ByteConverter.java:29)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getLong(AbstractJdbc2ResultSet.java:2150)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.internalGetObject(AbstractJdbc2ResultSet.java:142)
at
org.postgresql.jdbc3.AbstractJdbc3ResultSet.internalGetObject(AbstractJdbc3ResultSet.java:36)
at
org.postgresql.jdbc4.AbstractJdbc4ResultSet.internalGetObject(AbstractJdbc4ResultSet.java:296)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(AbstractJdbc2ResultSet.java:2703)
...
Usually followed later by this exception:
org.postgresql.util.PSQLException: Bad value for type long : ,
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.toLong(AbstractJdbc2ResultSet.java:2971)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getLong(AbstractJdbc2ResultSet.java:2163)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.internalGetObject(AbstractJdbc2ResultSet.java:142)
at
org.postgresql.jdbc3.AbstractJdbc3ResultSet.internalGetObject(AbstractJdbc3ResultSet.java:36)
at
org.postgresql.jdbc4.AbstractJdbc4ResultSet.internalGetObject(AbstractJdbc4ResultSet.java:296)
at
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(AbstractJdbc2ResultSet.java:2703)
...
Setup:
OS: Ubuntu 10.04
PG: 9.2
JDBC: postgresql-9.2-1001.jdbc4.jar
I'm also using PostGIS 2.0.1 jar, Apache Commons DBUtils, and DBCP.
I *believe* that it must have something to do with concurrent database
connections or connection reuse, but I haven't been successful at
creating a test case, despite trying for several days now.
Suggestions? I've got a mountain of data - if anyone needs more details.
--Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
pgsql-jdbc by date: