Just to put this on the record for 9.2: I've just thought of a way to further extend the READ ONLY optimizations to de facto READ ONLY transactions. Right now, when a dangerous structure is formed with three transactions (which consists of read-write dependencies from T0 -> T1 -> T2) and T2 is committed, we have an optimization where we recognize that nothing needs to be rolled back if T0 is READ ONLY and overlaps T2. We could extend this to de facto READ ONLY transactions (those which don't write to a permanent table, but fail to declare that up-front) where T0 overlaps T2 by holding off on rolling anything back until T2 actually does a write. We already have flags which track the relevant data, and we already use them to optimize de facto read only transactions where T0 commits before T1; but we could avoid a few false positives with this additional optimization. Definitely too late in the release cycle to be trying to add a new optimization, though. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
