Re: Possible bug / regression from generated keys

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: Possible bug / regression from generated keys
Дата
Msg-id CADK3HHKOfy3ODmOsy4bqL9mpcaicttCn6e8uNgrAmQS7jwYuAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Possible bug / regression from generated keys  (Peter Cooner <petriborg@gmail.com>)
Ответы Re: Possible bug / regression from generated keys
Список pgsql-jdbc
Well there is a relatively easy fix that would get rid of the problem. Currently we don't check the length of the array that we are trying to convert. However I'd like to understand how the problem is manifest before doing that.

Dave

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca



On Wed, Nov 7, 2012 at 6:24 PM, Peter Cooner <petriborg@gmail.com> wrote:
Yeah, though changing the JDBC driver is the lone modification
required to cause the problem.

I'll try switching around some of the code which should remove DBCP
from the system leaving only DbUtils. it will take a little more work
to pull DbUtils though.



On Wed, Nov 7, 2012 at 6:07 PM, Dave Cramer <pg@fastcrypt.com> wrote:
> Peter,
>
> I was afraid of that. So there are a few utilities between you and the
> driver.
>
> Dave
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
>
> On Wed, Nov 7, 2012 at 6:00 PM, Peter Cooner <petriborg@gmail.com> wrote:
>>
>> 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
>
>



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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Peter Cooner
Дата:
Сообщение: Re: Possible bug / regression from generated keys
Следующее
От: dmp
Дата:
Сообщение: Re: Possible bug / regression from generated keys