Timeout guard disabled with SET ... = 0

Warning — this works, but blocks traffic or rewrites data at scale.

What it catches

SET lock_timeout = 0 (or statement_timeout = 0) switches the safety off: zero means 'wait forever'. A migration that disables its timeouts can queue behind one slow query indefinitely — with all new traffic queueing behind it — precisely the stall the guard exists to prevent.

Fires on

SET statement_timeout = 0;
ALTER TABLE orders ADD COLUMN region text;

Do this instead

Set a short, finite timeout instead. If the operation legitimately needs long uninterrupted time (a large index build, say), that is a scheduled operational window — not a migration that silently waits forever whenever the lock is contended.

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

Catch this before it ships

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

Browse all 69 rules

← BV046 BV048 →