Locking & concurrencybeginnerPro runbook

Set sane statement, lock, and idle timeouts

By default statement_timeout, lock_timeout, and idle_in_transaction_session_timeout are all 0, unlimited. Setting them turns a runaway query or a stuck lock wait into a fast, clean error instead of an outage.

Problem

What you're actually looking at

The symptom as it shows up on a real server.

Out of the box PostgreSQL will let a query run forever, wait on a lock forever, and sit idle in a transaction forever. Those defaults turn small problems into incidents. Three timeouts, set sensibly, bound the damage.

Meridian wants a query that runs too long to be cancelled, and an update that cannot get its lock quickly to fail fast rather than pile up behind a blocker.

Simple terms

Out of the box PostgreSQL will happily let a query run forever, wait on a lock forever, and sit idle in an open transaction forever, all three limits default to zero, meaning unlimited. Those defaults are how small hiccups grow into outages. Setting statement_timeout, lock_timeout, and idle_in_transaction_session_timeout to sensible values turns a runaway query or a stuck lock wait into a quick, clean error instead of a pile-up.

ProCaptured evidence where the run produced it

Full runbook for this incident

The scenario above is free. What Pro unlocks is the fix: how to identify set sane statement, lock, and idle timeouts, the exact SQL to trace it, PostgreSQL 18 output for the steps we captured, the resolution path, and how to stop it recurring.
  • The full identify checklist, the exact signals that tell you it's this incident
  • Every diagnostic query; lab output is attached only to the steps we actually captured
  • The resolution path and the pitfalls that make it worse
  • Mitigation steps to stop it recurring, plus a verify-you're-done query

Card required. Cancel before day 7 and you are not charged.

Compare plans

ShareLinkedInX

Need the full procedure?

Pro runbooks finish the incident path

Free runbooks teach the shape. Pro opens the full step transcript, edge cases, and prevention depth.

FollowSubstackLinkedInnew errors · lab notes · hiring loops