Re: Connection.setReadOnly()

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Connection.setReadOnly()
Date: 2009-12-11 14:37:22
Message-ID: 4B225922.1090705@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Oliver Jowett wrote:
> John R Pierce wrote:
>> Oliver Jowett wrote:
>
>>> If your oracle developers don't want manually committed transactions,
>>> perhaps they should.. turn on autocommit.
>>>
>> otherwise, an app thats doing purely read queries has to periodically
>> issue a Commit(). I have to say, doing Commit() on read operations is
>> NOT at all intuitive.
>
> Maybe not, but it's a fairly well known quirk of Postgresql that
> long-running transactions don't work so well; the JDBC driver is no
> different to any other interface in this regard.

Does Pg have issues with long-running read-only transactions in
read-committed mode? Or are they an exception to the usual "avoid
long-running mostly-idle transactions" guideline?

Pg doesn't have to worry about retaining old rows in vacuum with such a
statement, because each new statement creates a new snapshot, so if it's
idle it effectively has _no_ snapshot and vacuum is free to clear old
rows. It doesn't need to keep track of anything to roll back, since the
transaction is read only.

So ... for READ COMMITTED, READ ONLY transactions, _are_ there any
VACUUM issues?

--
Craig Ringer

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Albe Laurenz 2009-12-11 15:20:36 Re: Connection.setReadOnly()
Previous Message Greg Stark 2009-12-11 12:09:04 Re: Connection.setReadOnly()