> 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,
> ...(snip)...
>
> Even if we thought that supporting Read Uncommitted would be a good
> idea, this would be an unacceptably unstable implementation of it.
Well, the thought of an unstable "dirty read" seems strange, but I get
your point that it isn't the SQL Standard's Read Uncommitted mode.
The use of this is clear though: allowing long running transactions
against unchanging data to not interfere with other activities. It will
also have importance in a Hot Standby mode.
So, even if this isn't Read Uncommitted exactly, it is a transaction
isolation mode that has utility for us and I would like to support it,
well documented and with appropriate cautions.
--
Simon Riggs
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment