Re: java.lang.OutOfMemoryError [Viruschecked]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 4 Feb 2003 19:22:06 +0000, snpe wrote:

Hello snpe, hello Barry,

as I saw just now, Nick's patch was committed... thanks a lot.
So I have to do the merge work I've done in early january a
second time... :-(
I corrected numerous bugs, I know it was a Megapatch, but as
I see now, the users WANT these URL parameters, they WANT the
explicit typing, and maybe they also WANT the fix for timestamps
<1000 ad (This was fixed, too).
Jeez. Yesterday I had checked the patch and found 2 conflicts;
as I checked out today, everything's a mess.

Sigh.

Patric

>Hello Barry,
>  What happen if I call two or more statement with setFetchSize, btw.

>   1. setFetchSize 10 for query on table a and table b
>   2. select * from a
>       select 10 rows from a
>   3. select * from b
>       select 10 rows from b
>   4. I want rows 11-20 from a, now
>   5. next 10 rows (11-20) from b

>etc

>in step 2 'execute' for query table a call 'BEGIN; DECLARE CURSOR  ...'
>in step 3 'execute' for query table b call again 'BEGIN; ...'
>Can I do this without nested transaction (savepoint)
>I think that close in ResultSet or Statement must call 'COMMIT' OR 'ROLLBACK', too

>Can You set parametar in driver URL (true or false) that use cursor automagic for true ?

>regards
>Haris Peco

>On Tuesday 04 February 2003 16:42, Barry Lind wrote:
>> Paul,
>>
>> A patch was just applied to cvs head to better deal with this.  The new
>> behavior is that by default you get the old behavior, but if you call
>> setFetchSize() it will turn on using cursors to incrementally fetch the
>> result.
>>
>> thanks,
>> --Barry
>>
>> PS.  I haven't yet got a new build for the web site, but should in a few
>> days, so in the meantime, if you want to try this out, you will need to
>> build from cvs sources.
>>
>> Paul Cullum wrote:
>> > I'm querying a table that has nearly 3 million records in it and when I
>> > call executeQuery() I get an a java.lang.OutOfMemoryError message.  My
>> > immediate thought was that it was strange that a safe fetch size wasn't
>> > used automatically so I then I decided to explicitly the fetch size by
>> > calling the Connection classes setFetchSize() method.  Apparently this
>> > is not implemented in the pg73jdbc3.jar driver.   I am surprised that
>> > the default fetch size is so great as to cause an OutOfMemoryError. What
>> > is the proper method for using JDBC to query result sets which are
>> > potentially large?
>> >
>> > Thanks,
>> > Paul
>> >
>> >
>> > ---------------------------(end of broadcast)---------------------------
>> > TIP 5: Have you checked our extensive FAQ?
>> >
>> > http://www.postgresql.org/users-lounge/docs/faq.html
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 5: Have you checked our extensive FAQ?
>>
>> http://www.postgresql.org/users-lounge/docs/faq.html


>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?

>http://archives.postgresql.org




PGP Public Key Fingerprint: 2636 F26E F523 7D62  4377 D206 7C68 06BB

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1 (C) 1997-1999 Network Associates, Inc. and its affiliated companies.

iQA/AwUBPkAtYHxoBrvMu8qQEQLMIQCgkhLzbMkB/SfHztwzd3YTSn+mtRMAn2DC
UU9LZVNnrOoOD+wJSDImwAo/
=2UCE
-----END PGP SIGNATURE-----