CREATE INDEX CONCURRENTLY failure within transaction blocks

Transactional DDL Constraints

PostgreSQL allows most schema modifications, such as ALTER TABLE, to be wrapped in a transaction block to ensure atomicity and rollback safety. This behavior ensures that catalog updates remain invisible to other sessions until the transaction commits.

Non-Transactional Operation Conflict

A specific conflict arises when attempting to use CREATE INDEX CONCURRENTLY. Because this operation requires multiple passes over the table and manages its own internal state to avoid locking out writes, it cannot be executed inside a transaction block.

When a migration strategy requires both a schema change and a concurrent index creation, the inability to wrap the latter in a BEGIN...COMMIT block creates a gap in rollback safety for the overall deployment process.

• How can a migration be structured to maintain atomicity when combining transactional DDL with non-transactional index creation?
• What is the recommended pattern for handling a failure during CREATE INDEX CONCURRENTLY if previous transactional changes in the same deployment must be reverted?