Re: Read Uncommitted

From: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: "Koichi Suzuki" <koichi(dot)szk(at)gmail(dot)com>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Read Uncommitted
Date: 2008-05-26 12:42:38
Message-ID: 20080526211713.84C8.52131E4D@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


"Koichi Suzuki" <koichi(dot)szk(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2008-05-26 12:49:03 Re: Proposal: temporal extension "period" data type
Previous Message Koichi Suzuki 2008-05-26 12:11:02 Re: Read Uncommitted