RE: [HACKERS] READ COMMITTED isolevel is implemented ...

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Vadim Mikheev
> Sent: Saturday, January 30, 1999 1:41 PM
> To: Hiroshi Inoue
> Cc: hackers(at)postgreSQL(dot)org
> Subject: Re: [HACKERS] READ COMMITTED isolevel is implemented ...
>
>
> Hiroshi Inoue wrote:
> >
> > > Subject: [HACKERS] READ COMMITTED isolevel is implemented ...
> > >
> > > and this is now the DEFAULT isolevel.
> > >
> >
> > It's different from current(v6.4.2).
>
> First, I think that DEFAULT isolevel must be configure-able.
>
> > The way will be provided to upgrade user's current code ?
>
> Even SERIALIZABLE isolevel in MVCC is different from
> one in locking systems. There is only one way to don't
> change anything in applications - use table level locking.
> Should we provide ability to turn MVCC off?
>

I think in most cases SEIALIZABLE is sufficient for upgrading.
So it is preferable that we can change default isolation level
easily.
I believe that SET TRANSCTION ISOLATION LEVEL is per
transaction command(i.e it is necessary for every transaction
which is different from default).
Another command to set per connection default is necessary
as Thomas Lockhart wrote about "autocommit".

We can have the default be "set autocommit on" (probably
with an equals sign like our other "set" variables) and we can
have it be a run-time option like DATESTYLE and other settable
parameters. So you can configure your server or your client
environment to always behave the way you prefer.

> > > Processing updates in READ COMMITTED isolevel is much
> > > complex than in SERIALIZABLE one, because of if transaction T1
> > > notices that tuple to be updated/deleted/selected_for_update
> > > is changed by concurrent transaction T2 then T1 has to check
> > > does new version of tuple satisfy T1 plan qual or not.
> >
> > How about UPDATE t set x = x + 1 where .... ?
> >
> > The values of x used for x = x + 1 are at the time when statement
> > started ?
> > It seems that this case also requires re-execution.
>
> x + 1 is in target list of execution plan. And so when child plan
> is executed, new value of x is used to evaluate target list
> expressions. Executor uses tuple from child plan as new version
> of tuple.
>

Oracle(Version7) seems to work as you mentioned.
Sorry.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp