Re: Possible bug / regression from generated keys

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.
>>
>>
>
>
>