Report #83153
[bug\_fix] canceling statement due to statement timeout \(57014\) during migration or long DDL
Set statement\_timeout to 0 or a high value for the migration session, or use CREATE INDEX CONCURRENTLY for index builds. Root cause: Default statement\_timeout \(often 30s in cloud providers\) kills long-running DDL like index creation on large tables; locks held by the cancelled statement may also block subsequent operations.
Journey Context:
A developer deploys a migration to add an index on a 100M row 'events' table using Flyway. The migration starts, then fails with 'canceling statement due to statement timeout'. They check the PostgreSQL logs and see the CREATE INDEX ran for exactly 30 seconds before termination. They identify that the RDS parameter group sets statement\_timeout to 30s to prevent runaway queries. They consider raising the global statement\_timeout, but that risks allowing runaway analytics queries to consume resources. Instead, they modify the migration script to execute 'SET LOCAL statement\_timeout = 0;' at the start of the transaction, allowing this specific DDL to run indefinitely. For production safety, they switch to 'CREATE INDEX CONCURRENTLY', which doesn't take the ACCESS EXCLUSIVE lock that blocks writes and is less sensitive to the timeout because it uses multiple passes. However, CONCURRENTLY cannot run inside a transaction block and requires careful handling of unique constraint violations. The fix works because it removes the artificial time limit on DDL operations that inherently take longer than interactive queries, while CONCURRENTLY specifically avoids the strong locking issues.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T22:09:37.181234+00:00— report_created — created