# 4.5 The Looking Glass Windows (Isolation Levels)
Now that we understand the [[Chapter 4/4.4 - The Pinky Swear (Transactions)|Pinky Swear]], we need to talk about the **view**.
When you step into a **Looking Glass Room** (a Transaction), the Lazy Elephant has to decide exactly how much of the outside Depot you are allowed to see through the windows. This is known as the **Isolation Level**, and Postgres offers three distinct types of windows.
## 1. Read Committed (The Standard Window)
This is the default view. The window is clear, but it only shows what people have *finished* (committed).
> [!NOTE]
> **No Dirty Secrets**: In some other databases, you can see someone's half-finished work through the window (a **Dirty Read**). But the Lazy Elephant is a gentleman. He refuses to show you anything that isn't committed. In Postgres, even at the lowest level, your window is always clean of "dirty" data.
Imagine you look out the window and see a red suitcase sitting on a cart. You blink, and in that split second, another elephant commits a change that swaps it for a blue suitcase. When you look again, the red one is gone!
This is called a **Non-repeatable Read**. Because the window is "live" to committed changes, your view can change mid-transaction. It's fast, it's low-effort for the elephant, and for 99% of tasks, it's exactly what you need.
## 2. Repeatable Read (The Magic Painting)
If you need more stability, you ask for a **Repeatable Read**.
The moment you step into the room, the elephant takes a high-resolution Polaroid of the entire Depot and tapes it over the window. This is **Snapshot Isolation**.
No matter how many suitcases are moved, added, or burned outside, your "Magic Painting" never changes. You see the world exactly as it was the moment your pinky swear began. Even if you look a thousand times, that red suitcase will stay red.
**Why the Elephant Screams**: If you try to update a suitcase that someone else changed while you were looking at your painting, the elephant will scream (an error) and cancel your transaction!
Imagine you’re trying to paint a mustache on the red suitcase in your "Magic Painting." But in the real world, someone has already stolen that suitcase and replaced it with a blue one. When the elephant tries to apply your mustache to the real world, he notices the suitcase has been swapped! Because he only knows what the world looked like in the painting, he has lost his "baseline" and refuses to guess what to do. He cancels your work to keep the world safe.
## 3. Serializable (The Single-File Door)
The third and most powerful window is **Serializable**. This is Postgres's crown jewel, and one of the features that truly sets it apart from most other databases.
Imagine the elephant has installed a **Single-File Door** to the depot. He employs a sophisticated guard using **SSI (Serializable Snapshot Isolation)**, who silently monitors every transaction's read set and write set. The guard's guarantee: no matter how many elephants work *in parallel*, the final result is **identical to if they had walked through that single door one at a time.**
This sounds paranoid, but it prevents a subtle class of bugs called **Write Skew**—where two concurrent transactions each read something, each write something, and together produce an impossible result that *neither* would have caused alone. A classic example: two doctors both read "there's one on-call doctor available" and each schedules themselves off-duty. Now there are zero on-call doctors. Neither transaction violated a constraint—but the combined result is a catastrophe.
With `SERIALIZABLE`, the elephant would detect the conflict and cancel one of them before it happened.
```sql
-- Stepping through the single-file door
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
-- ... your work here ...
COMMIT; -- May fail with "ERROR: could not serialize access due to concurrent update"
```
> [!TIP]
> If a serializable transaction fails, it is safe to simply **retry it**—the error means "someone else got there first, try again." An elephant who loses at the door simply gets back in line.
It's like a bouncer who ensures that even if a hundred elephants are working, the result is the same as if they had walked through the door **one at a time, in a single-file line**. It is perfectly safe, but it makes the elephant very thoughtful.
### Choosing Your Window
You can tell the elephant exactly which window you want for your session or your next transaction:
```sql
-- Checking the current view
SHOW transaction_isolation;
-- Read Committed (the default): live view of committed data
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- Repeatable Read: stable snapshot from the start of the transaction
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- Serializable: full SSI protection, as if running one-at-a-time
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
-- ... your stable, serializable view begins here
COMMIT;
```
Remember: the clearer the window, the more work the elephant has to do to keep it clean!
---
| ← Previous | ↑ Table of Contents | Next → |
| :--- | :---: | ---: |
| [[Chapter 4/4.4 - The Pinky Swear (Transactions)\|4.4 The Pinky Swear (Transactions)]] | [[Learn You a Postgres for Great Good\|Home]] | [[Chapter 4/4.6 - The Infinite Calendar (Transaction ID Wraparound)\|4.6 The Infinite Calendar (Transaction ID Wraparound)]] |