All quizzesMedium
Isolation Levels — Series 3
Preview — 3 of 10 questions
A transaction runs SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;. Does it actually see other transactions' uncommitted (dirty) writes?
ANo — PostgreSQL accepts the READ UNCOMMITTED syntax for SQL-standard compatibility, but internally treats it identically to READ COMMITTED; PostgreSQL's MVCC architecture never allows one transaction to see another's uncommitted changes, at any isolation level, so a true dirty read is simply not possible in PostgreSQL
BYes — that's the entire purpose of requesting READ UNCOMMITTED
CIt depends on whether fsync is enabled
DOnly superuser sessions can actually see uncommitted data under this level
The SQL standard only requires REPEATABLE READ to prevent non-repeatable reads, technically still allowing phantom reads (new rows appearing on a re-run query) at that level. Does PostgreSQL's REPEATABLE READ allow phantom reads?
AYes — PostgreSQL's REPEATABLE READ follows the SQL standard exactly and still permits phantom reads, matching the minimum requirement
BIt depends on whether an index exists on the queried table
CNo — PostgreSQL's REPEATABLE READ is implemented via a single, fixed snapshot taken at the start of the transaction, and that same snapshot is used for every query in the transaction — so a re-run query sees neither modified existing rows nor newly inserted rows that another transaction committed afterward, which means PostgreSQL's REPEATABLE READ is actually stronger than the SQL standard's minimum requirement and prevents both anomalies
DPhantom reads are only possible under SERIALIZABLE, never under any weaker level
A transaction sets SAVEPOINT before_risky;, runs a statement that fails, then issues ROLLBACK TO SAVEPOINT before_risky;. What's different about this compared to a plain ROLLBACK;?
AThey're identical; ROLLBACK TO SAVEPOINT always ends the whole transaction just like plain ROLLBACK
BROLLBACK TO SAVEPOINT can only be used once per transaction, ever
CROLLBACK TO SAVEPOINT commits everything before the savepoint automatically
DROLLBACK TO SAVEPOINT undoes everything back to that specific savepoint's state — including clearing the error that made the transaction "aborted" — but leaves the transaction itself open, ready to accept new statements; a plain ROLLBACK (with no savepoint reference) discards the entire transaction and ends it completely
Sign up free to play
Answer all 10 questions (7 more), see explanations for every answer, and track your score.