"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
