When starting up SonarQube for the first time on a fresh database, when specifying a specific schema, with the parameter currentSchema, like this:
The correct schema is picked up for tables creation, but the primary key constraints are always registered in the table pg_namespace with the public default schema, ignoring the custom my_schema schema specified.
Later, when performing a SonarQube upgrade, when a PK needs to be deleted, SonarQube migration job is searching for PK constraints in pg_constraint and pg_namespace tables, with this kind of query:
Because PK constraints are all registered on the public schema, it's not possible to retrieve the correct constraint name on a multi-schema environment.
Steps to reproduce:
Create a new sonarqube database
- Create a new schema public2 on this database
- Start SonarQube on this schema with
- Notice that nspname is wrong: