PGthesev1database
ErrorsTriageCookbook
ArchitectureLessonsInterview
Pricing
Runbooks/Locking & concurrency

Runbook category

Locking & concurrency

A lock problem does not throw an error. It just stops, which is why it is usually diagnosed last. These runbooks read the wait graph directly — who blocks whom, and on what kind of lock — and then bound the damage with timeouts, SKIP LOCKED queues, and advisory locks so the next incident ends in a fast error instead of a stalled table.

  • Detect and resolve lock contention

    Queries hang with no error and no progress, and you need the wait graph now.

    Free
  • Stop idle-in-transaction sessions from holding locks

    A session sits idle in transaction, holding its locks and pinning vacuum.

    Pro
  • Build a safe job queue with SKIP LOCKED

    Several queue workers all fight over the same top rows and serialize.

    Pro
  • Set sane statement, lock, and idle timeouts

    Every timeout ships as 0, so one runaway statement turns into an outage.

    Pro
  • Coordinate work with advisory locks

    Two app instances run the same cron job at the same time, twice.

    Pro
  • Keep ALTER TABLE from blocking your app

    One migration waits on a lock and every reader behind it queues too.

    Pro
  • Resolve row-level lock contention from SELECT FOR UPDATE

    A session waits on wait_event transactionid while every table-lock dashboard stays green.

    Pro

Other categories

Query performance16Indexing9Vacuum & bloat8Observability16Schema migrations6WAL & replication7

Browse all runbooks →

thesev1database

Evidence-first PostgreSQL reference. Every claim is reproduced in a Docker lab and cited back to the official manual — no hand-waving.

Firefight

ErrorsTriageCookbook

Learn

ArchitectureLessonsPathwaysLibrary mapGlossaryGUCsInterview prep

More

PricingSign in

Company

ContactTermsPrivacyRefunds