Explicit LOCK TABLE held for the rest of the migration

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

What it catches

LOCK TABLE holds its lock until the transaction commits. Migration runners wrap the file in one transaction, so an explicit lock taken early is held across every remaining statement — a manual outage whose duration is the rest of the migration.

Fires on

LOCK TABLE orders IN ACCESS EXCLUSIVE MODE;

Do this instead

Drop the explicit LOCK TABLE — DDL acquires exactly the lock it needs, and a SET lock_timeout guard bounds how long it may queue. If statements truly must be serialized against traffic, take the weakest sufficient lock mode as late in the migration as possible, never up front.

SET lock_timeout = '5s';
ALTER TABLE orders ADD COLUMN region text;
-- the ALTER takes its own ACCESS EXCLUSIVE, guarded and brief —
-- no explicit LOCK TABLE needed

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

← BV021 BV023 →