Must-share information (formatted with Markdown):
- which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension) 9.9.1 (previously on v9.8)
- how is SonarQube deployed: zip, Docker, Helm. Docker
- what are you trying to achieve. Clarification
- what have you tried so far to achieve this. n/a
A year ago or so, we upgraded from v7.3 on a server with separate postgres DB on a different server. Then I upgraded to v7.9 and finally at v8.9. Each step of the way, I was opening the url of https://urlofserver/setup. Usually that ended up with a database action of some sort. After the application was upgraded, then I had to upgrade postgres from v12 to v13.
My question is:
What is happening when there is an action to do after one goes to https://url/setup after the application upgrade?
It was my thought that a reindex or database maintenance was happening, but after the recent upgrade from v9.8 to v9.9.1, we had extremely slow analysis times. For example an analysis used to take 12-15sec was taking over 1 hour.
Upon re-reading the release notes for v9.9.1, we performed the following:
" I thought this was included as part of the post upgrade when you go to https://url/setup, but we ran into the same issue when upgrading from docker running v9.8 to v9.9.1. However, we upgrade SQ from v9.5(?) to v9.8 and prior to that major update from v7.
I see in the v9.9.1 notes there is a section for postgres.
Additional database maintenance
Once you’ve finished a technical upgrade, you should rebuild database indexes and refresh database statistics before starting SonarQube and reanalyzing your projects.
For PostgreSQL, that means executing three operations:
REINDEX DATABASE <db>
According to the PostgreSQL documentation:
In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a VACUUM is done.
Our analysis are much quicker and in line than what they were prior to v9.9.1.
Please explain what is happening at https://url/setup and perhaps better communicate (ie: move it out from under Oracle heading) that 3 postgres commands need to be run upon every upgrade.