Skip site navigation (1) Skip section navigation (2)

Re: OutOfMemory

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Guido Fiala <guido(dot)fiala(at)dka-gmbh(dot)de>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: OutOfMemory
Date: 2004-03-30 22:53:24
Message-ID: 4069FA64.3010302@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Guido Fiala wrote:
> By chance i'am currently at the same point, unfortunately i don't get it 
> working as expected.
> 
> -after calling ResultSet.last() the getRow() still reflects the fetchsize (how 
> to get the number of records for e.g. a progress-bar?)

That sounds like a bug; last() should take you to the very last record 
of the resultset independent of the fetchsize. Can you submit a testcase 
showing this?

(... later ...) Hold on -- doesn't last() require a scrollable 
resultset, which means you're not using a cursor behind the scenes? I 
think the driver does not throw an exception if you try to use 
last()/absolute()/etc with FETCH_FORWARD_ONLY (it should!) but instead 
just gives you the wrong results.. not great, but this is not only the 
fault of the driver :)

> -calling "ResultSet.next()" at the "last" fetched record does not fetch more 
> results automatically, Statement.fetchMoreResults() gives me null-pointer - 
> how do i actually get the next fetch?

It should be transparent. i.e. last() should take you to the *very end* 
of the resultset, fetching forward until there are no more results. You 
shouldn't ever see the boundaries between fetches (other than as a 
slight delay on next()).

> -according to the documentation only "FETCH_FORWARD" is supported, which is 
> not always suitable

This is simply because no-one has implemented the logic to support 
scrollable resultsets backed by a cursor yet. Patches are welcome!

> Does it have some meaning that it only works if 
> Connection.setAutoCommit(false) is used?

Yes -- otherwise we'd need to use a cursor WITH HOLD and manage it more 
carefully. Currently we rely on end-of-transaction closing the cursors, 
and that scheme doesn't work with autocommit on so we don't use cursors 
in that case.

This is actually a tradeoff between storing the resultset on the backend 
and storing it on the java process -- WITH HOLD is not free, someone has 
to store the data once the transaction is gone. I think the backend does 
a better job of paging out results etc though.

> I had a quick look through the sources and found the term 
> "server-prepared-statement" is used under certain conditions - what's this 
> for?

That's unrelated to cursor use; this is to do with transforming 
repeatedly executed queries into a PREPARE/EXECUTE form. It's not on by 
default.

> I was also thinking about using the "SELECT ... LIMIT x OFFSET y" instead, but 
> this might lead to unexpected side effects if multiple users are changing 
> data - the user gets only a momentary snapshot then, if the order has changed 
> in between some records will never be seen, others twice and so on.
> 
> Any nice idea to solve this?

Wrap your queries in a transaction if you want transactional isolation. 
Also you really want an ORDER BY if you're using LIMIT/OFFSET.

-O

In response to

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2004-03-30 23:07:47
Subject: Re: JDBC driver's (non-)handling of InputStream:s
Previous:From: Oliver JowettDate: 2004-03-30 22:39:58
Subject: Re: JDBC driver's (non-)handling of InputStream:s

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group