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