Re: problem with new autocommit config parameter and jdbc

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: snpe <snpe(at)snpe(dot)co(dot)yu>
Cc: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, Rod Taylor <rbt(at)rbt(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: problem with new autocommit config parameter and jdbc
Date: 2002-09-10 21:50:52
Message-ID: 20020910144611.K28261-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc


On Tue, 10 Sep 2002, snpe wrote:

> On Tuesday 10 September 2002 07:46 pm, scott.marlowe wrote:
> > What if it's a select for update? IF that failed because of a timout on a
> > lock, shouldn't the transaction fail? Or a select into? Either of those
> > should make a transaction fail, and they're just selects.
> Ok.Any lock or update,delete, insert (and all ddl command) start transaction
> (select for update, too), but simple select no.Select don't change data and no
> transaction - this process cannot lost consistency (any command with error
> too).

At least in serializable isolation level you'll probably get different
results if a transaction commits between those two selects based on
whether a transaction is started or not. Should two serializable selects
in the same session see the same snapshot when autocommit is off?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oliver Elphick 2002-09-10 22:08:00 Re:
Previous Message Jan Wieck 2002-09-10 21:27:32 Re: Rule updates and PQcmdstatus() issue

Browse pgsql-jdbc by date

  From Date Subject
Next Message Stephan Szabo 2002-09-10 23:25:10 Re: problem with new autocommit config parameter and jdbc
Previous Message Daniel Serodio 2002-09-10 21:01:05 Jar file's manifest