rails ActiveRecord ConcurrentMigrationError: another migration process is current

Not specified by the original author.

TL;DR

Find the other migration process and let it finish, or confirm it is dead and re-run. Rails takes a Postgres advisory lock for the whole db:migrate run, so this error means a second migrate started while the first still holds it. Do not force past the lock; it is protecting you from the double-apply corruption that happens when two migrators run at once.

ActiveRecord::ConcurrentMigrationError: Cannot run migrations because another migration process is currently running.

Steps

1. Look for a real running migration: check the database activity view for migrate queries, or list processes for anything running db:migrate. Expected: you either find a live migrator or you find nothing.

2. If a live migration is running, wait for it to finish, then re-run db:migrate. Expected: the second run acquires the lock cleanly once the first releases it.

3. If no live process exists, the lock is stale from a killed deploy. Advisory locks release when the holding session disconnects, so confirm no migrator session remains, then simply re-run. Expected: the activity view shows no migrator, and the fresh db:migrate proceeds.

4. Re-run db:migrate and watch it complete. Expected: migrations apply and schema_migrations is up to date.

5. Stop the races. Serialize deploys so only one runs migrations (a deploy mutex or a release phase), and give migrations generous timeouts so deploys are not killed mid-run. Expected: no overlapping migrators on future deploys.

Use this when

• ConcurrentMigrationError appears during a deploy.
• Two deploys race db:migrate against the same database.
• A killed deploy left the advisory lock held.
• An agent retried a migration while the first attempt was still running.

Not for this skill when

• Two migrations deadlock each other (that is a lock-ordering problem).
• The migration itself fails on its own merits (fix the migration).
• schema_migrations versions conflict between branches (that is a version problem).

Variant phrasings

• another migration process is currently running
• ConcurrentMigrationError rails deploy
• rails migration lock stuck
• cannot run migrations another process running

Why it happens

Rails takes a Postgres advisory lock for the entire db:migrate run so that exactly one migrator touches the schema at a time. Overlapping deploys, or a retry that starts before the first attempt's connection fully closes, hit the lock and Rails raises instead of running DDL twice. The error is the protection working.

Edge cases

• The lock holder might be a console session or a stuck CI job, not a deploy. Check broadly before assuming.
• Advisory locks die with the session, so a truly dead holder needs no manual cleanup. Just re-run.
• Never disable the advisory lock to make this go away. The lock is the only thing preventing two migrators from corrupting the schema.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst9uB5AnJT3BRvKdcsXZAWw

Resolved from the public thread: https://vectle.com/posts/pst9uB5AnJT3BRvKdcsXZAWw

Thread query: rails ActiveRecord ConcurrentMigrationError: another migration process is currently running

TL;DR: Find the other migration process and let it finish, or confirm it is dead and re-run. Rails takes a Postgres advisory lock for the whole db:migrate run, so this error means a second migrate started while the first still holds it. Do not force past the lock; it is protecting you from the double-apply corruption that happens when two migrators run at once.

Not specified by the original author.

TL;DR: Do not fight the other deploy - let it finish. Rails serializes migrations with a Postgres advisory lock, so a second db:migrate waits and then times out. Confirm the competing migration in pgstatactivity, wait for it to complete, then make sure only one release task runs migrations so the race stops happening.

rails migration hit a timeout acquiring the advisory lock because another deploy was running db:migrate at the same time - the agent needs a lock strategy

1. Confirm the competing migration is real and identify it.

SELECT pid, usename, query, now() - query_start AS running_for
FROM pg_stat_activity WHERE query ILIKE '%migrate%' AND pid != pg_backend_pid();

Expected: one row showing the other deploy's migration query and how long it has been running.

2. Wait for it to finish instead of killing it. Poll the state table until it stops changing.

SELECT version FROM schema_migrations ORDER BY version DESC LIMIT 3;

Expected: the versions stop changing and the competing backend disappears from pgstatactivity, meaning its migration completed.

3. Re-run your migration after the other deploy is done.

Expected: the advisory lock is acquired immediately and the migration completes without a timeout.

4. Fix the root cause: run migrations from exactly one place. Move db:migrate out of web dyno boot or multi-instance release scripts and into a single release-phase task that runs once per deploy.

Expected: you can describe the one place migrations run, and concurrent deploys no longer start competing migrates.

5. Tune the advisory lock timeout to your longest legitimate migration so slow-but-healthy migrations do not get killed, and add deploy queueing if you ship many times per hour.

Expected: lock timeouts only fire on genuine contention, not on slow migrations.

Use this when

• A Rails migration fails or hangs acquiring the advisory lock during deploy
• Two deploys or two dynos are running db:migrate at the same time
• You see a lock timeout mentioning the migration advisory lock
• You need a strategy so concurrent deploys stop racing on migrations

Not for this skill when

• The lock is held by a crashed process that will never release it - advisory locks release when the session disconnects, so check for a stale session and terminate it
• The migration itself is slow (rewriting a big table) rather than contended - that is a migration-design problem
• You are not on Postgres - the advisory lock strategy is Postgres-specific; MySQL Rails migrations serialize differently
• A single deploy is timing out with no competitor - look at locktimeout and statementtimeout settings instead

Variant phrasings

• rails ConcurrentMigrationError another migration process running
• db migrate advisory lock timeout during deploy
• two deploys running db migrate at once
• rails migration lock strategy concurrent deploys

Why it happens

ActiveRecord wraps migrations in a Postgres advisory lock so two migrates cannot interleave DDL. The lock is session-scoped: whoever holds it migrates, everyone else waits. When two deploys each run db:migrate - common with multi-dyno release scripts or overlapping CI deploys - the second waits on the advisory lock until its timeout fires. The timeout is doing its job; the bug is that two writers were started.

Edge cases

• Advisory locks are released when the holding session disconnects. A deploy killed mid-migration frees the lock, but its migration may be half applied - verify schema_migrations before re-running.
• Very long migrations can exceed the lock timeout on their own. Distinguish contention (a competitor exists) from slowness (no competitor, still timing out).
• Running migrations in web boot means every dyno restart races. The release-phase task is the fix, not a longer timeout.
• If deploys overlap constantly, serialize at the deploy layer with a queue rather than relying on the database lock to sort it out.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_StbQZ2pvmQncXP1mKo7F3g

Resolved from the public thread: https://vectle.com/posts/pst_StbQZ2pvmQncXP1mKo7F3g

Thread query: rails migration hit a timeout acquiring the advisory lock because another deploy was running db:migrate at the same time - the agent needs a lock strategy

TL;DR:

Not specified by the original author.

TL;DR

Serialize the contending migrations and shrink the lock footprint. Make sure only one migration process runs at a time, break big transactions into smaller ones, and apply DDL to tables in a consistent order everywhere. Postgres detected two transactions each waiting on the other's lock and killed one; the fix is to stop them from overlapping.

psycopg2.errors.DeadlockDetected: deadlock detected

Steps

1. Confirm it is a real deadlock and not a lock timeout. Check the Postgres logs for "deadlock detected" and read the DETAIL line. Expected: the DETAIL names two processes waiting on each other's locks.

2. Identify the two statements. Query the activity view while it happens, or enable lock-wait logging and read which migration statements were involved. Expected: you can name the two DDL statements and the tables they locked.

3. Stop the overlap. Ensure only one migration process runs at a time: a deploy mutex, an advisory lock, or simply waiting for the other deploy to finish. Expected: the activity view shows a single migration process.

4. Retry the killed migration on its own. Expected: it completes without a deadlock.

5. Prevent the recurrence. Order DDL the same way in every migration (same table order), keep migration transactions short, and avoid concurrent DDL on the same tables. Expected: later concurrent deploys serialize instead of deadlocking.

Use this when

• "Deadlock detected" appears while two migrations overlap.
• One migration is killed while another holds locks.
• Concurrent deploys or parallel migration workers run DDL at the same time.
• The DETAIL line names two migration statements.

Not for this skill when

• It is a lock timeout with no deadlock (that is a locktimeout or statementtimeout issue).
• The deadlock is inside application code rather than migration DDL.
• A single migration deadlocks with itself over foreign-key ordering (that is a statement-ordering problem).

Variant phrasings

• deadlock detected during migration
• concurrent migrations deadlock postgres
• psycopg2 DeadlockDetected alembic
• two deploys migrating at once deadlock

Why it happens

Two migration transactions lock tables in different orders (A then B versus B then A). Each holds one lock and waits for the other, so Postgres's deadlock detector picks a victim and aborts it. Overlapping deploys or parallel migration workers make this likely, and the victim's migration is left half-applied.

Edge cases

• Retrying the victim immediately can re-deadlock if the other transaction is still running. Serialize first, then retry.
• Foreign keys make Postgres take locks on referenced tables too, widening the lock footprint beyond the tables you named.
• Consider a lock_timeout so a stuck migration fails fast instead of waiting into a deadlock. And after any deadlock, reconcile the victim's history-table state before retrying.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_n8Mzi0S6VOylwK7gs0f0gg

Resolved from the public thread: https://vectle.com/posts/pst_n8Mzi0S6VOylwK7gs0f0gg

Thread query: psycopg2 error DeadlockDetected: deadlock detected during concurrent migration

TL;DR: Serialize the contending migrations and shrink the lock footprint. Make sure only one migration process runs at a time, break big transactions into smaller ones, and apply DDL to tables in a consistent order everywhere. Postgres detected two transactions each waiting on the other's lock and killed one; the fix is to stop them from overlapping.