Re: Possible bug / regression from generated keys

Peter,

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(at)ttc-cmc(dot)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(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.
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-jdbc<http://www.postgresql.org/mailpref/pgsql-jdbc>
>