Liquibase 4.8.0 upgrade causing issue with one of the existing change sets

Question

I have a changeset which does not get executed after I have upgrade liquibase-core to 4.8.0 version.

I am using postgres DB here.

Fails with below error:

caused by: liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for change set db/changelog/liquibase/release/db.changelog-release-xml

 Reason: liquibase.exception.DatabaseException: ERROR: column "xyz" of relation "abc" is an identity column [Failed SQL: (0) ALTER TABLE abc ALTER COLUMN xyz SET DEFAULT nextval('custom_seq')]

Not sure what is wrong here.

What do I change to make this right ? What's an identity column ?

Answer 1

An "identity" column is an auto-increment/serial column. The error is coming from the database, where a changeset is running which tries to set the default to nextval('custom_seq') and it doesn't like that. Probably because it's already marked as auto-increment/serial/identity in the database.

There could be a couple reasons for this, and I don't have enough info from the question to know. It does sound like the same changelog was running with a previous liquibase version?

Some potential options:

1. There has been a change to how the filepath is figured. Liquibase identifies each changeset with not just the id and author field, but also the lookup path to the file. If there is a bug in how that path is figured, Liquibase would see it as a new changeset and re-apply it which would fail with a "column is already an identity". If it is a bug causing that, it may have been fixed in later versions of Liquibase.

2. There was a change in the SQL generated for a particular change type. Possibly to make it more correct even, but because of your database's state that new SQL is not valid for some reason.

To help differentiate which is your case, check:

• What changeset is throwing the error, and do you expect that to be running against your database right now?
• If you didn't expect it to run, it's probably #1 above. How is the path shown in the log different than what is stored in the databasechangelog table for that changeset?
• If you did expect it to run, what is the changeset saying should be done and is the changeset not actually valid? Or would you have expected it to work given your database state?