Re: [HACKERS] READ COMMITTED isolevel is implemented ...
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] READ COMMITTED isolevel is implemented ... |
Дата | |
Msg-id | 36B2E7D9.38D7D0CC@krs.ru обсуждение исходный текст |
Ответ на | RE: [HACKERS] READ COMMITTED isolevel is implemented ... ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Список | 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
В списке pgsql-hackers по дате отправления: