On Sun, 2008-05-25 at 20:10 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 www.2ndQuadrant.com 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
