Re: Read Uncommitted
От | ITAGAKI Takahiro |
---|---|
Тема | Re: Read Uncommitted |
Дата | |
Msg-id | 20080526211713.84C8.52131E4D@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Read Uncommitted ("Koichi Suzuki" <koichi.szk@gmail.com>) |
Ответы |
Re: Read Uncommitted
|
Список | pgsql-hackers |
"Koichi Suzuki" <koichi.szk@gmail.com> wrote: > Because Read Uncommitted shows all the "yet not committed" version, it > seems to me that there's no problem to show the new version of tuples > to Read Uncommitted transacations as follows: Another transaction could update the retuned tuple, which is the newest at that time, and the reading transaction could read updated version of the tuple. We might return different version of identical tuples, although there is *no timing* multiple tuples exist. This is an another side of the problem shown by Tom, where we have no tuples if we hide new tuples and then old tuples are removed. For example, "SELCT count(*) FROM tbl" by READ UNCOMMITTED transactions should always return correct values even if we only runs UPDATEs at the same time. I guess defining READ UNCOMMITTED is quite difficult -- it should be efficient, but should not be chaotic. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: