I was thinking about true serializability, and started thinking that
there are a lot of special cases where true serializability can be
achieved without modification.
For instance, the following is problematic:
BEGIN; SELECT count(*) FROM mytable; ...
because future insert/update/deletes may be based on that count, so we
essentially would have to lock out write to mytable.
However,
BEGIN READ ONLY; SELECT count(*) FROM mytable; ...
is fine, because snapshot isolation already gives true serializability.
And inserts (that don't read any tables) are always safe as well.
Also, in snapshot isolation mode, simple updates and deletes that have a
simple predicate involving a unique key also give true serializability.
It seems like the kinds of transactions that fall outside of these
special cases are exactly the kind of transactions where serializability
is most important -- reading an unknown number of tuples and then
writing. People executing transactions like that are probably willing to
pay some performance cost to ensure correct results.
How hard would it be to reliably detect the transactions for which
snapshot isolation already means true serializability?
Regards,Jeff Davis
