Search first

• I searched and no similar issues were found

Description

After updating to 5.0.3, the default-schema-name parameter no longer sets the correct schema for changesets run with runInTransaction:false, making them fail to resolve unqualified objects in the non-default schema.

Steps To Reproduce

Consider this simple changelog file:

--changeset test:1
CREATE TABLE IF NOT EXISTS test (id TEXT PRIMARY KEY);
--changeset test:2 runInTransaction:false
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_test_id ON test (id);

and this simplified configuration via the Liquibase Gradle plugin:

activities.register(name) {
    arguments = mapOf(
        "logLevel" to "info",
        "changelogFile" to "/path/to/changelog.sql",
        /* ↓ this is the important part; 
         * assumes `myschema` exists in the DB and it is where I want to create the `test` table 
         * and where Liquibase tables are located */
        "defaultSchemaName" to "myschema",
        "url" to dbUrl,
        "username" to dbUser,
        "password" to dbPassword,
    )
}

Observe the update task pass on 5.0.2 but fail with

[2026-06-09 15:21:14] SEVERE [liquibase.integration] Migration failed for changeset db/query-engine.changelog-master.sql::2::test:
     Reason: liquibase.exception.DatabaseException: ERROR: relation "test" does not exist [Failed SQL: (0) CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_test_id ON test (id)]

on 5.0.3

Expected/Desired Behavior

I expect this setup to continue working unmodified.

Liquibase Version

5.0.3

Database Vendor & Version

PostgreSQL 17.5

Liquibase Integration

Gradle plugin

Liquibase Extensions

No response

OS and/or Infrastructure Type/Provider

MacOS 26

Additional Context

I have verified that the issue is not with the Gradle plugin nor our setup. I used debug logging to make sure the defaultSchemaName parameter is set to the expected value and it seems to be correctly translated to the --default-schema-name CLI argument by the Gradle plugin.

I am fairly confident this is happening due to this change. Apparently, the SEARCH_PATH is now set using SET LOCAL in Postgres which only makes the config option valid for a single transaction, not the entire session. Postgres' docs explain why it doesn't work for out-of-transaction changesets specifically:

LOCAL

Specifies that the command takes effect for only the current transaction. After COMMIT or ROLLBACK, the session-level setting takes effect again. Issuing this outside of a transaction block emits a warning and otherwise has no effect.

(emphasis mine).

Note that while this this seems to have been the intention of that PR, I still consider it a bug. The docs do not mention anything about the setting only being in effect for changesets that run in a transaction, nor there seems to be any alternative configuration option that would allow working around this limitation. Also, this clearly appears to be a regression as the same changelog used to work in prior versions, but stopped working after an update with no mention in the release notes about any breaking change of this sort.

Lastly, introducing such a breaking change in a patch version update is surely not intended 🙂

Are you willing to submit a PR?

• I'm willing to submit a PR (Thank you!)