require-attach-partition-check

What It Detects

ATTACH PARTITION without a matching CHECK constraint scans the whole table under ACCESS EXCLUSIVE to validate the bound.

Why It's Dangerous

ATTACH PARTITION is meant to be a catalog operation, and mostly it is. The exception is validation: PostgreSQL proves every row in the incoming table satisfies the partition bound by reading all of them, while holding ACCESS EXCLUSIVE on both the incoming table and the parent — so the entire partitioned table, every partition, is unavailable for the duration. An existing CHECK that implies the bound lets PostgreSQL skip the scan, moving the work to VALIDATE CONSTRAINT, which takes a lock that allows reads and writes.

Bad Example

ALTER TABLE events ATTACH PARTITION events_2026_01
  FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');
-- Full scan of events_2026_01, ACCESS EXCLUSIVE on the whole hierarchy

Good Example

-- 1. Add a CHECK matching the bound, without validating it yet
ALTER TABLE events_2026_01
  ADD CONSTRAINT events_2026_01_bound
  CHECK (ts >= '2026-01-01' AND ts < '2026-02-01') NOT VALID;

-- 2. Validate it under a lock that lets traffic through
ALTER TABLE events_2026_01 VALIDATE CONSTRAINT events_2026_01_bound;

-- 3. The attach is now catalog-only
ALTER TABLE events ATTACH PARTITION events_2026_01
  FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

Configuration

Disable this rule:

# .migrationpilotrc.yml
rules:
  MP094: false

Or change its severity:

# .migrationpilotrc.yml
rules:
  MP094:
    severity: warning