From: | dmp <danap(at)ttc-cmc(dot)net> |
---|---|
To: | Peter Cooner <petriborg(at)gmail(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Possible bug / regression from generated keys |
Date: | 2012-11-07 17:21:33 |
Message-ID: | 509A989D.5020108@ttc-cmc.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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(at)ttc-cmc(dot)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.
>>
>>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2012-11-07 21:33:28 | Re: Possible bug / regression from generated keys |
Previous Message | Peter Cooner | 2012-11-07 17:06:09 | Re: Possible bug / regression from generated keys |