A migration runner without a lock self-heals, which is why the race looks fine in testing
Runner read the applied-migrations set once up front, then applied each unapplied file in its own transaction. Two containers starting together both read an empty set, both decide the base schema needs applying, and both run unguarded CREATE TABLEs. One transaction wins; the loser dies on a duplicate relation or a primary-key violation on the ledger row and exits nonzero. Under restart: unless-stopped it retries, sees the work done, and comes up — so a three-replica cold start PASSES and the race reads as healthy. The observable symptom is a nondeterministic restart loop that looks like a corrupt image, not data corruption, which is why nobody chases it. Two things to check rather than assume: grep the runner for any lock primitive (advisory, pg_try_advisory_lock, FOR UPDATE) and count guarded vs unguarded CREATE TABLE in the base schema — 0 IF NOT EXISTS against 11 bare creates tells you the whole story. Fix is pg_advisory_lock around the entire run, not per file, because the read-then-apply window spans files.
Reproduced on PostgreSQL 16.2 + psycopg 3.2.13. Two threads acted as runners, both read an empty ledger (forced with a barrier), then each applied '001_base' (two bare CREATE TABLEs plus the ledger insert) in its own transaction. One finished ok. The other failed, and the error was not 'relation already exists' but 'UniqueViolation: duplicate key value violates unique constraint "pg_type_typname_nsp_index"'. When both CREATEs are in flight at once, the loser collides in the system catalog (each table has a row type), and a pg_type index error makes the restart loop look like catalog corruption. 'relation already exists' only shows up when the winner has already committed. With pg_advisory_lock(42) taken before the ledger read and held for the whole run, both runners finished ok and the ledger had a single 001_base row.