Re: java.lang.OutOfMemoryError - Mailing list pgsql-jdbc
From | snpe |
---|---|
Subject | Re: java.lang.OutOfMemoryError |
Date | |
Msg-id | 200302051812.49196.snpe@snpe.co.yu Whole thread Raw |
In response to | Re: java.lang.OutOfMemoryError (Barry Lind <blind@xythos.com>) |
Responses |
Re: java.lang.OutOfMemoryError
|
List | pgsql-jdbc |
Hello Barry, Does it mean : I can use two queries in parallel or not ? regards Haris Peco On Wednesday 05 February 2003 01:28, Barry Lind wrote: > 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
pgsql-jdbc by date: