Simon Riggs <simon@2ndquadrant.com> writes:
> At the moment, a long running SQL Statement can prevent xmin moving
> forward, which can result in VACUUM and HOT not being able to remove row
> versions effectively. My proposal is that a Read Uncommitted transaction
> would not prevent row removal, which then offers no guarantee that the
> "correct" answer would be returned. Which is *exactly* what that
> transaction isolation level was designed for.
This seems like a remarkably bad idea. It has no use that I can see for
anything except shooting oneself in the foot.
> 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.
regards, tom lane
