-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
6.4.14, 7.2.11
-
6.04
-
6
-
Severity 3 - Minor
-
1
-
Summary
In some unidentified cases optionconfiguration table has logical duplicates. In some cases it can cause performance problems: see JRASERVER-42282
Steps to Reproduce
- Run SQL
// Check all duplicated options, query should return 0 SELECT fieldid,optionid,fieldconfig, count(*) FROM optionconfiguration group by fieldid,optionid,fieldconfig having count(*)>1
Expected Results
Select returns 0 results
Actual Results
Select return non zero results:
OPTIONID FIELDCONFIG COUNT(1) 11900 10000 4 12306 10000 4 ... 13982 10000 18 14022 10000 18 14024 10000 18 ...
Notes
Table description:
\d optionconfiguration Table "public.optionconfiguration" Column | Type | Modifiers -------------+-----------------------+----------- id | numeric(18,0) | not null fieldid | character varying(60) | optionid | character varying(60) | fieldconfig | numeric(18,0) | sequence | numeric(18,0) | Indexes: "pk_optionconfiguration" PRIMARY KEY, btree (id) "fieldid_fieldconf" btree (fieldid, fieldconfig) "fieldid_optionid" btree (fieldid, optionid)
Example:
select * from optionconfiguration limit 10; id | fieldid | optionid | fieldconfig | sequence -------+-----------+----------+-------------+---------- 10512 | issuetype | 3 | 10300 | 0 10513 | issuetype | 5 | 10300 | 1 10514 | issuetype | 10100 | 10300 | 2
Workaround
If the above SQL returns any rows, you are affected by the problem. In this case, please raise a ticket on https://support.atlassian.com, referring to this bug report and ask for assistance on de-duplicating the table.
- causes
-
JRASERVER-42282 On large instances the createmeta REST endpoint can take a very long amount of time to return results or cause JIRA to OOM
- Closed