How deeply does PostgreSQL Mistakes and How to Avoid Them cover serializable isolation level?

Explains SSI, anti-dependency cycles, write skew, failure behavior, concurrency overhead, and retry requirements without implementation-level internals.

Serializable isolation level

As explained in PostgreSQL Mistakes and How to Avoid Them

SERIALIZABLE is a SQL transaction isolation level that requires concurrent transactions to produce results equivalent to some serial execution.

SERIALIZABLE is the strictest transaction isolation level: concurrent transactions must behave as though they ran in some serial order. PostgreSQL uses Serializable Snapshot Isolation (SSI) to detect dangerous read/write dependencies instead of relying on blocking explicit locks. section 6.9

A tempting synchronization strategy is to lock objects explicitly. That can make sessions block one another, increasing query duration, latency, and interactive waits. SERIALIZABLE avoids that blocking model, but applications must tolerate serialization failures and retry the affected transaction. section 6.13 section 6.9

Detecting write skew

Transaction T1 reads three rows where active = true. Transaction T2 deactivates one row, and T1 then calculates an average over active rows, now seeing only two. This predicate-read write skew forms an anti-dependency cycle, also called a G2 serialization anomaly. Under SERIALIZABLE, PostgreSQL detects the conflict and may raise ERROR: could not serialize access due to read/write dependencies among transactions; retry the transaction rather than treating the error as a successful result. section 6.9

Use SERIALIZABLE when synchronization correctness matters and the application can retry failed transactions:

Prefer it over broad explicit locking when blocking and lock-management complexity would hurt latency. section 6.13 section 6.9
Expect slightly reduced concurrency from anomaly detection, balanced against the absence of query blocking. section 6.9
Keep retry handling in the client, or consider PostgreSQL advisory locks when synchronization belongs in application-controlled coordination. section 6.9

How PostgreSQL Mistakes and How to Avoid Them covers it

Cover of PostgreSQL Mistakes and How to Avoid Them

liveBook manning.com

Read PostgreSQL Mistakes and How to Avoid Them on liveBook Get the book at manning.com

Also explained in

liveBook manning.com

Java Persistence with Spring Data and Hibernate epubSerializable isolation is the strictest transaction isolation level and makes concurrent transactions behave as if executed serially.
liveBook manning.com

100 SQL Server Mistakes and How to Avoid ThemSerializable is a transaction isolation level that provides the strongest standard protection against concurrent-read consistency anomalies, including phantom reads.

Compare how 3 books explain serializable isolation level →

Related concepts

isolationkind of · Isolation is the separation of components, processes, resources, or contexts to limit interaction, interference, or the propagation of effects between them.
snapshot isolationequivalent to · Snapshot isolation is a transaction-isolation method in which each transaction reads a consistent versioned snapshot of committed data while concurrent writes are isolated from that view.
phantom readaddresses · A phantom read is a concurrency anomaly in which repeated predicate-based reads return different sets of matching rows because another transaction changed the qualifying data.
lockingalternative to · Locking is a synchronization technique that restricts concurrent access to shared resources or protected operations.
deadlockaddresses · A deadlock is a state in concurrent execution where two or more activities are indefinitely blocked by dependencies on resources, events, or progress that cannot become available.

This explainer was generated by Manning's knowledge graph from the text of PostgreSQL Mistakes and How to Avoid Them. The section links point to the parts of the book it draws on.