I agree that such instant freeze of the whole database status is not
feasible. We may be able to find compromise what to show and what to
hide. Anyway, read uncommitted cannot guarantee repeatable read and
can provide only "approximate" result. Even though we are successful
to show instant freeze, the same SQL may provide different result at
the next instant.
2008/5/26 ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>:
>
> "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
>
>
>
--
------
Koichi Suzuki