Re: java.lang.OutOfMemoryError

Haris,

The current code does a "BEGIN; DECLARE...". I intend to change this to
no longer include the BEGIN and instead only allow the use of cursors
if the driver is running in non-autocommit mode. Since postgres doesn't
allow cursors to be used across transactions, a commit should also
invalidate the result set. The current behavior of including the BEGINs
will cause warning messages and thus the need for the change. However
since postgres doesn't yet support nested transactions, there isn't a
need for the commit/rollback you suggest.

thanks,
--Barry

snpe wrote:
> 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
>