RE: [HACKERS] READ COMMITTED isolevel is implemented ...
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] READ COMMITTED isolevel is implemented ... |
Дата | |
Msg-id | 000301be4be4$3c4c1b80$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | READ COMMITTED isolevel is implemented ... (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
Hello All, > -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Vadim Mikheev > Sent: Saturday, January 30, 1999 2:55 AM > To: hackers@postgreSQL.org > Subject: [HACKERS] READ COMMITTED isolevel is implemented ... > > > and this is now the DEFAULT isolevel. > It's different from current(v6.4.2). The way will be provided to upgrade user's current code ? > I run some tests to ensure how it works, but not so much. > Unfortunately, currently it's not possible to add > such tests to regression suit because of they require > concurrent transactions. We could write simple script to > run a few psql-s simultaneously and than just put queries > to them (through pipes) in required order. I have no time > for this now... > > 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. Thanks. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: