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
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() |