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