Re: Autocommit, isolation level, and vacuum behavior

From: Jack Orenstein <jack(dot)orenstein(at)hds(dot)com>
To: Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Autocommit, isolation level, and vacuum behavior
Date: 2008-09-12 13:51:51
Message-ID: 48CA73F7.10405@hds.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tomasz Ostrowski wrote:
> On 2008-09-11 18:03, Jack Orenstein wrote:
>
>>> When you do:
>>> result = query("select something from sometable")
>>> then all rows of a result will be cached by a client program.
>> I am very sure this is not happening. Maybe some rows are being
>> cached (specifying fetch size), but certainly not all of them. It
>> used to, with older drivers, (7.4?) but I've been using 8.1 drivers
>> (at least) for a long time. Maybe some result set options you're
>> using cause such memory usage?
>
> Wanna bet?
>
> http://jdbc.postgresql.org/documentation/83/query.html#query-with-cursor
> | There a number of restrictions which will make the driver silently
> | fall back to fetching the whole ResultSet at once. (...) The
> | Connection must not be in autocommit mode. The backend closes cursors
> | at the end of transactions, so in autocommit mode the backend will
> | have closed the cursor before anything can be fetched from it.
>
> So, when you turn on autocommit then it is caching it all. Fetch size is
> ignored.

Well that explains what I've been seeing (autocommit on scan producing behavior
that looks like SERIALIZABLE). Not the behavior I would prefer, but I understand
it now.

Jack

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jack Orenstein 2008-09-12 13:52:29 Re: Autocommit, isolation level, and vacuum behavior
Previous Message Andrus 2008-09-12 13:27:27 Converting string to IN query