  A DBMS allows trading consistency for efficiency through the allocation of
isolation levels that are strictly weaker than serializability. The robustness
problem asks whether, for a given set of transactions and a given allocation of
isolation levels, every possible interleaved execution of those transactions
that is allowed under the provided allocation, is always safe. In the
literature, safe is interpreted as conflict-serializable (to which we refer
here as conflict-robustness). In this paper, we study the view-robustness
problem, interpreting safe as view-serializable. View-serializability is a more
permissive notion that allows for a greater number of schedules to be
serializable and aligns more closely with the intuitive understanding of what
it means for a database to be consistent. However, view-serializability is more
complex to analyze (e.g., conflict-serializability can be decided in polynomial
time whereas deciding view-serializability is NP-complete). While
conflict-robustness implies view-robustness, the converse does not hold in
general. In this paper, we provide a sufficient condition for isolation levels
guaranteeing that conflict- and view-robustness coincide and show that this
condition is satisfied by the isolation levels occurring in Postgres and
Oracle: read committed (RC), snapshot isolation (SI) and serializable snapshot
isolation (SSI). It hence follows that for these systems, widening from
conflict- to view-serializability does not allow for more sets of transactions
to become robust. Interestingly, the complexity of deciding serializability
within these isolation levels is still quite different. Indeed, deciding
conflict-serializability for schedules allowed under RC and SI remains in
polynomial time, while we show that deciding view-serializability within these
isolation levels remains NP-complete.
