Know which lock mode your statement takes
Every statement takes a table-level lock whether you asked for one or not, and only the conflict rules decide whether that is invisible or an outage. Read the mode your own statement acquires before you ship it, not after.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Lock modes are named for history rather than behaviour — ROW EXCLUSIVE is a table-level lock, and SHARE conflicts with ordinary writes. The only thing that matters is which modes conflict, and that is knowable in advance. Most lock outages are simply a team that did not know what their statement would take.
A developer adds a column to Meridian's orders table. Within seconds every SELECT, INSERT and UPDATE against that table is queued behind an ACCESS EXCLUSIVE lock, the connection pool drains as requests pile up, and the host's CPU climbs while almost no useful work completes. The migration itself was instant; the lock it held was not.
In plain English
Every statement quietly takes a lock on the table it touches, even a plain SELECT. Most of the time you never notice, because the light locks are compatible with each other and any number of them can be held at once. The trouble comes from the heavy end: a few statements take a lock that is incompatible with everything, including reads. When one of those arrives, every later query on that table has to wait — and because they queue rather than fail, the symptom looks like the database got slow, or busy, rather than that it is blocked. The fix is not cleverness during the incident; it is knowing before you run a statement which lock it takes and what that lock will stop.
Full runbook for this incident
- The full identify checklist — the exact signals that tell you it's this incident
- Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
More in this category
Other Locking & concurrency runbooks
Neighbouring incidents that share the same diagnostic surface.
Connected
How this connects to the rest of the library
A live view of this page's real cross-references — what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.
Fixes these errors