# 6.3 The Narrow Bridge Sometimes the basement isn't the problem. Sometimes the problem is other elephants. ## The Congestion Crisis Imagine the warehouse has several **Narrow Bridges** that connect different aisles. Only one elephant can cross a bridge at a time. If two elephants arrive at once, one must wait. In Postgres, these bridges are **Locks** and **Latches**. - **Locks**: These are high-level traffic signals. If Elephant A is currently painting a suitcase (an `UPDATE`), Elephant B cannot even look at that suitcase until the paint is dry. - **Latches (and LWLocks)**: These are internal, light-speed traffic signals. If two workers try to write on the same "Whiteboard" (a shared memory buffer) at the exact same microsecond, they will bump heads. ## The Deadlock Dance The most dangerous version of this is the **Deadlock**. - Elephant A is waiting for the bridge to Aisle 1, but he’s currently blocking the path to Aisle 2. - Elephant B is waiting for the bridge to Aisle 2, but he’s currently blocking the path to Aisle 1. They will both stand there until the end of time, politely waiting for the other to move. Fortunately, Postgres has a "Deadlock Detector" (a very grumpy goose) that flies around and honks loudly at one of them until they give up and walk away, breaking the stalemate. ## Identifying the Jam In your reports, look for: - **`Lock:relation`**: "I'm waiting for another elephant to finish with this whole table." - **`Lock:transactionid`**: "I'm waiting for another elephant to finish their entire pinky-swear session." - **`LWLock:BufferContent`**: "I'm waiting 50 microseconds for someone to stop scribbling on this shared whiteboard." Congestion isn't about resource hunger; it's about **Coordination Failure**. --- [[Chapter 6/6.2 - Disk Wait|← 6.2 - Disk Wait]] | [[Chapter 6/6.0 - The Waiting Game|↑ 6.0 - The Waiting Game]] | [[Chapter 6/6.4 - Workloads|6.4 - Workloads →]]