Re: Read Uncommitted

As an addendum for the archives only, I would add:

On Sun, 2008-05-25 at 20:10 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:

> > The implementation is trivial, namely that the calculation of global
> > xmin would ignore Read Uncommitted transactions.
> 
> This proposed implementation seems to have very little to do with
> what most people would think Read Uncommitted does.  In particular it
> does not agree with the SQL spec, which says that Read Uncommitted
> permits transactions to see the results of as-yet-uncommitted
> transactions.  As an example, suppose that old transaction T1 reads
> a table that always contains exactly one live row, but T2 has modified
> that row since T1 started.  Per spec what Read Uncommitted means is that
> T1 may see the modified version before T2 commits.  This would not
> implement that behavior, though.  What this implementation would mean is
> that after T2 commits, we might vacuum away the old version, causing T1
> to see *nothing* in the table:
> 
>     * T1 scans the new row version, doesn't return it because T2 not
>       yet committed;
>     * T2 commits;
>     * VACUUM removes old row version;
>     * T1 never finds old row version to return.
> 
> Even if we thought that supporting Read Uncommitted would be a good
> idea, this would be an unacceptably unstable implementation of it.

We might think we can widen the snapshot so we see the new row versions
after update. That won't work either, because we don't check to see
whether multiple row versions are part of the same row. We always assume
that each row can have at most one visible row version for each
snapshot. So trying to see the new row versions instead would likely
result in viewing too many rows in most cases.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support