Re: Possible bug / regression from generated keys

I can replicate the problem within our code at will, but I've been
unable to produce a standalone test case despite my best efforts.

I started building this test case by using just the postgresql jar,
then tried adding postgis jar, but have yet to get around to trying to
writing one that uses DBCP or DbUtils.

it always seems to happen on the same column, and it doesn't seem to
ever happen on the first row off the batch insert, but that could be
just by chance.

On Wed, Nov 7, 2012 at 4:33 PM, Dave Cramer <pg@fastcrypt.com> wrote:
> 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@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
>
>

--
Pete
"Yates went on to say that using MS formats left a fresh, minty feeing
in user's mouths while every time an open [format] is used a kitten
dies." -- maggard (on slashdot)

perl -lne '(1x$_) !~ /^1?$|^(11+?)\1+$/ && print "$_ is prime"'

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc