From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] READ COMMITTED isolevel is implemented ... |
Date: | 1999-01-30 11:07:05 |
Message-ID: | 36B2E7D9.38D7D0CC@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Agreed, but I never worked with configure stuff...
> 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".
Oracle uses ALTER SESSION command for this.
> > > > 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.
Isn't this the same you told in first message?
And if so - what "sorry" means? -:)
Ok. T1 executes UPDATE t SET x = x + 1 WHERE y = 2 and sees
that row (x = 1, y = 2) is updated by T2 to be (x = 3, y = 2).
What is the result of T1 update? In postgres the result
will be (x = 4, y = 2), not (x = 2, y = 2). Is it ok?
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-01-30 11:09:06 | Re: [HACKERS] READ COMMITTED isolevel is implemented ... |
Previous Message | The Hermit Hacker | 1999-01-30 08:05:50 | Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed) |