Chapter 26 — Quiz

14 questions. Answers at the bottom.

Multiple choice

Q1. A transaction is: - A) A single SQL statement only - B) An all-or-nothing unit of work (BEGIN…COMMIT/ROLLBACK) - C) A backup - D) An index

Q2. Atomicity means: - A) Constraints always hold - B) All statements succeed together or none do - C) Committed data survives crashes - D) Transactions don't interfere

Q3. Durability is guaranteed primarily by: - A) Indexes - B) The write-ahead log (WAL) - C) Constraints - D) MVCC alone

Q4. A dirty read is: - A) Reading committed data - B) Reading another transaction's uncommitted (possibly-rolled-back) changes - C) Reading the same row twice - D) A phantom row

Q5. A non-repeatable read is: - A) Reading uncommitted data - B) Getting different values for the same row read twice in one transaction - C) A new row appearing in a range - D) A deadlock

Q6. A phantom read is: - A) Same row, different value - B) Re-running a range query and getting different rows (insert/delete by another tx) - C) Reading uncommitted data - D) A lost update

Q7. PostgreSQL's default isolation level is: - A) Read Uncommitted - B) Read Committed - C) Repeatable Read - D) Serializable

Q8. Under Read Committed, which is still possible? - A) Dirty reads - B) Non-repeatable and phantom reads - C) Nothing - D) Only deadlocks

Q9. Serializable isolation guarantees: - A) The fastest performance - B) Results as if transactions ran one at a time (serially) - C) No locking ever - D) Dirty reads

Q10. MVCC means: - A) Readers block writers - B) Multiple row versions, so readers and writers don't block each other - C) Only one transaction at a time - D) No transactions

Q11. Under Serializable, the application should: - A) Never commit - B) Be ready to retry transactions that fail with a serialization error - C) Disable constraints - D) Use Read Uncommitted instead

True/False

Q12. Read Committed prevents dirty reads but not non-repeatable or phantom reads. (True / False)

Q13. Long-running transactions are harmless. (True / False)

Short answer

Q14. Why is "place an order" (insert order + insert items + decrement inventory) a transaction, and what could happen without one?

---

Answer key

Q1 — B. All-or-nothing unit of work.

Q2 — B. Atomicity = all or none.

Q3 — B. The WAL records changes durably before applying them.

Q4 — B. Reading uncommitted (possibly rolled-back) data.

Q5 — B. Same row, different value within one transaction.

Q6 — B. Different rows in a re-run range query.

Q7 — B. Read Committed.

Q8 — B. Non-repeatable and phantom reads remain possible (dirty reads don't).

Q9 — B. As-if-serial execution — the strongest correctness.

Q10 — B. Multiple versions → readers and writers don't block each other.

Q11 — B. Retry serialization failures (they're expected).

Q12 — True. That's exactly Read Committed's guarantee/limits.

Q13 — False. Long transactions hold snapshots, can block VACUUM (dead-tuple cleanup), and increase contention. Keep them short.

Q14. The three steps must all succeed or all fail — otherwise you could insert the order and items but fail to decrement inventory (overselling), or decrement inventory without recording the order (lost stock). A transaction makes them atomic: a crash or error mid-way rolls back all of them, so the database is never left in a half-applied, inconsistent state.

Scoring: 12–14 you understand transactional correctness; 9–11 re-drill the phenomena/levels table; below 9, do the two-session exercises.