Liquibase failed to update Postgres BDR cluster

Hello, I’ve tried to deploy Keycloak 12.0.2 to Kubernetes cluster with a server based Postgres Bi-Directional Replication (BDR) cluster outside of Kubernetes. Unfortunately some of the Liquibase scripts generates the following SQL command (keycloak/jpa-changelog-9.0.0.xml at 66dfa32cd569a7416de21b4dc04db212e8fccce5 · keycloak/keycloak · GitHub):


This failed with the following error:

14:10:56,434 ERROR [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 69) Error has occurred while updating the database: 
liquibase.exception.MigrationFailedException: Migration failed for change set META-INF/jpa-changelog-9.0.0.xml::9.0.0-increase-column-size-federated-fk::keycloak:
Reason: liquibase.exception.DatabaseException: ERROR: ALTER TABLE ... ALTER COLUMN TYPE which cannot be automatically cast to new type may not affect replicated tables on a BDR node
Where: "xact rep": true, "ddl rep": true, "ddl locking": all in pglogical plugin bdr in the preprocess_ddl callback

What we have tried to resolve this:

  • Alter table manually and set correct type in advance. That didn’t help as Liquibase tries to repeat this SQL command again and looks like BDR cluster doesn’t like this USING directive that is generated with Liquibase automatically.
  • That’s working fine with disabling BDR but that’s not a safe and good solution especially in production. Moreover you need to repeat all these commands manually on each BDR Postgres node.
  • There are not much options we can change on the BDR cluster side too.

I’m interesting if anybody also faced with similar problems (not specifically with Postgres but maybe with different products like Oracle or MS SQL Server) and if so how you have resolved this?

We have decided to go ahead with executing manual update in the format its supported by BDR Postgres cluster. After executing manual update from failed scripts we have inserted missing record to databasecahngelog table and launched deployment again. After this deployment was successful.