Exclusive-lock DDL without a lock_timeout guard
Note — this works and blocks nothing, but a performance regression is likely.
What it catches
An ACCESS EXCLUSIVE request queues behind any long-running query — and every new query queues behind it. Without SET lock_timeout, one slow report turns a metadata-only ALTER into a site-wide stall of unbounded length. A short lock_timeout makes the migration fail fast and retryable instead.
Fires on
ALTER TABLE orders ADD COLUMN region text;Do this instead
SET lock_timeout at the top of every migration that takes strong locks. If the lock cannot be acquired quickly the migration fails fast and can be retried at a quieter moment — instead of queueing, with all new traffic queueing behind it.
SET lock_timeout = '5s';
ALTER TABLE orders ADD COLUMN region text;
-- can't get the lock in 5s → fail fast, retry later; traffic never stalls This rule runs in the hosted service on Startup and above — add --remote with a team token, or use the GitHub Action: npx bolvrk check migration.sql