SonarQube upgrade from 9.9.3 to 9.9.4 issue with stuck queries

Upgrading from 9.9.3 to 9.9.4

SonarQube database hosted on RDS Postgres 15.6. SonarQube pod is running in EC2 Amazon Linux 2 machine.

Sonar upgrade was successful, however, while loading the projects or starting new sessions with SonarQube, database CPU is peaking up and reaching to 99.8 % resulting in complete halt of operations. When reverted back to 9.9.3 version, it starts working fine again.

During the CPU issue, a few queries can bee seen stuck in the background. Most commonly, below one

Sonarqube RDS CPU getting increase due to query

select
   
  i.kee as kee,
  i.rule_uuid as ruleUuid,
  i.severity as severity,
  i.manual_severity as manualSeverity,
  i.message as message,
  i.message_formattings as messageFormattings,
  i.line as line,
  i.locations as locations,
  i.gap as gap,
  i.effort as effort,
  i.status as status,
  i.resolution as resolution,
  i.checksum as checksum,
  i.assignee as assigneeUuid,
  i.author_login as authorLogin,
  i.tags as tagsString,
  i.rule_description_context_key as ruleDescriptionContextKey,
  i.issue_creation_date as issueCreationTime,
  i.issue_update_date as issueUpdateTime,
  i.issue_close_date as issueCloseTime,
  i.created_at as createdAt,
  i.updated_at as updatedAt,
  r.is_external as "isExternal",
  r.plugin_rule_key as ruleKey,
  r.plugin_name as ruleRepo,
  r.language as language,
  r.security_standards as securityStandards,
  p.kee as componentKey,
  i.component_uuid as componentUuid,
  p.module_uuid_path as moduleUuidPath,
  p.path as filePath,
  root.kee as projectKey,
  i.project_uuid as projectUuid,
  i.issue_type as type,
  i.quick_fix_available as quickFixAvailable,
   
  n.uuid is not null as isNewCodeReferenceIssue
  
  
  from issues i
  inner join rules r on r.uuid=i.rule_uuid
  inner join components p on p.uuid=i.component_uuid
  inner join components root on root.uuid=i.project_uuid
  left join new_code_reference_issues n on i.kee = n.issue_key
  where i.kee in
   (  
   $1
   , 
   $2
   , 
   $3
   , 
   $4
   , 
   $5
   , 
   $6
   , 
   $7
   , 
   $8
   , 
   $9
   , 
   $10
   , 
   $11
   , 
   $12
   , 
   $13
   , 
   $14
   , 
   $15
   , 
   $16
   , 
   $17
   , 
   $18
   , 
   $19
   , 
   $20
   , 
   $21
   , 
   $22
   , 
   $23
   , 
   $24
   , 
   $25
   , 
   $26
   , 
   $27
   , 
   $28
   , 
   $29
   , 
   $30
   , 
   $31
   , 
   $32
   , 
   $33
   , 
   $34
   , 
   $35
   , 
   $36
   , 
   $37
   , 
   $38
   , 
   $39
   , 
   $40
   , 
   $41
   , 
   $42
   , 
   $43
   , 
   $44
   , 
   $45
   , 
   $46
   , 
   $47
   , 
   $48
   , 
   $49
   , 
   $50
   , 
   $51
   , 
   $52
   , 
   $53
   , 
   $54
   , 
   $55
   , 
   $56
   , 
   $57
   , 
   $58
   , 
   $59
   , 
   $60
   , 
   $61
   , 
   $62
   , 
   $63
   , 
   $64
   , 
   $65
   , 
   $66
   , 
   $67
   , 
   $68
   , 
   $69
   , 
   $70
   , 
   $71
   , 
   $72
   , 
   $73
   , 
   $74
   , 
   $75
   , 
   $76
   , 
   $77
   , 
   $78
   , 
   $79
   , 
   $80
   , 
   $81
   , 
   $82
   , 
   $83
   , 
   $84
   , 
   $85
   , 
   $86
   , 
   $87
   , 
   $88
   , 
   $89
   , 
   $90
   , 
   $91
   , 
   $92
   , 
   $93
   , 
   $94
   , 
   $95
   , 
   $96
   , 
   $97
   , 
   $98
   , 
   $99
   , 
   $100
   )

Hey there.

The first thing I would suggest is some database maintenance activities.

I can confirm that when the issue was faced, VACUUM was run on the database. However, it did not resolve the issue.
ANALYZE was not executed explicitly which can be tried. I’ll update if this will resolve the issue.