Does Liquibase Support a Configurable Timeout for Whole Changeset Execution?

Answer

Yes. Liquibase provides a timeout attribute on the <changeSet> element that aborts the entire change set after the specified number of seconds and marks it as failed.

How the timeout works

• The attribute is available starting with Liquibase 3.5; earlier versions ignore it.
• When present, Liquibase executes the change set in a separate thread and calls Thread.join(timeout * 1000).
• If the thread does not finish within the period, Liquibase interrupts the thread, throws a timeout exception, and attempts to roll back the enclosing database transaction (if the driver supports transactional DDL).
• If the timeout attribute is omitted, the change set runs without a time limit.

Applying a timeout to the whole update

Liquibase does not expose a command‑line‑level global timeout for update. To achieve a whole‑update timeout without editing each individual change set, you can:

1. Wrap all desired change sets in a single outer change set that contains only a <include> reference to the changelog file (or nest them), and add the timeout attribute to that outer change set.
2. Alternatively, add the timeout attribute to each change set you want to guard; the attribute is inherited by default when using <includeAll> with a relativeToChangelogFile flag.

Interaction with transactions, locks, and preconditions

• On databases that support transactional DDL (e.g., PostgreSQL, MySQL with InnoDB), the interrupt triggers a rollback of the current transaction, leaving the database in its pre‑change‑set state.
• On databases where DDL cannot be rolled back (e.g., Oracle, SQL Server for certain statements), a timeout may leave partially applied changes; Liquibase marks the change set as failed in DATABASECHANGELOG but does not undo the work.
• External locks, preconditions, and context checks are evaluated before the timed thread starts. If a timeout occurs after those checks have passed, the lock is released only when the interrupted thread terminates; otherwise the lock may persist until the JVM exits or the lock times out independently.

Verification steps

1. Check your Liquibase version: liquibase --version (must be ≥ 3.5).
2. Create a test change set containing a long‑running statement, e.g.:

   <changeSet id="timeout-test" author="test" timeout="5">
     <sql>SELECT pg_sleep(10);</sql>
   </changeSet>

3. Run liquibase update and observe that execution stops after ~5 seconds with an exception containing the word “timeout”.
4. Inspect the DATABASECHANGELOG table; the row for this change set should have EXECUTED = false and ERRORMSG mentioning the timeout.