Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-20010

Equal on two RANK window functions create wrong result

Details

    Description

      The following code results into a wrong result in MariaDB must of the time. It is not completely deterministic, but about 80% of all executions trigger a wrong execution:

      CREATE SCHEMA A;
       
      CREATE TABLE A.A (A INTEGER, E BIGINT);
       
      INSERT INTO A.A VALUES (4, -2), (3, -1);
       
      SELECT RANK() OVER (ORDER BY D.C) = RANK() OVER (ORDER BY B.A) FROM (SELECT 5 AS C FROM A.A) AS D, (SELECT A.E AS A FROM A.A) AS B;
      

      MariaDB returns 0, 0, 0, 1. Postgres and MySQL both return 0, 0, 1, 1, which is - manually verified - the correct answer. Therefore, I expect that MariaDB should also return this.

      We need both RANK window function calls and the equal - erasing one of the RANKs with the equal returns the correct results.

      I checked versions 10.4.5 and 10.4.6, I don't know if the bug occurs in previous versions. In MySQL, the query works.

      Attachments

        Issue Links

          Activity

            alice Alice Sherepa added a comment -

            Thanks a lot for the report!
            Reproduced as described on 10.2-10.4:

            create table t1 (a int, b int);
            insert into t1 values (4, -2), (3, -1);
             
            select b, rank() over (order by c) , rank() over (order by dt1.b)
            from 
            (select 5 as c from t1) as dt, 
            (select b from t1) as dt1;
             
            select b, rank() over (order by c) , rank() over (order by dt1.b), 
            rank() over (order by c) = rank() over (order by dt1.b) 
            from 
            (select 5 as c from t1) as dt, 
            (select b from t1) as dt1;
            

            on non-debug versions - wrong results:

            10.2.24

            MariaDB [test]> select b, rank() over (order by c) , rank() over (order by dt1.b)
                -> from 
                -> (select 5 as c from t1) as dt, 
                -> (select b from t1) as dt1;
            +------+--------------------------+------------------------------+
            | b    | rank() over (order by c) | rank() over (order by dt1.b) |
            +------+--------------------------+------------------------------+
            |   -2 |                        1 |                            1 |
            |   -2 |                        1 |                            1 |
            |   -1 |                        1 |                            3 |
            |   -1 |                        1 |                            3 |
            +------+--------------------------+------------------------------+
            4 rows in set (0.00 sec)
             
            MariaDB [test]> select b, rank() over (order by c) , rank() over (order by dt1.b), 
                -> rank() over (order by c) = rank() over (order by dt1.b) 
                -> from 
                -> (select 5 as c from t1) as dt, 
                -> (select b from t1) as dt1;
            +------+--------------------------+------------------------------+---------------------------------------------------------+
            | b    | rank() over (order by c) | rank() over (order by dt1.b) | rank() over (order by c) = rank() over (order by dt1.b) |
            +------+--------------------------+------------------------------+---------------------------------------------------------+
            |   -1 |                        1 |                            1 |                                                       1 |
            |   -2 |                        1 |                            2 |                                                       0 |
            |   -2 |                        1 |                            2 |                                                       0 |
            |   -1 |                        1 |                            4 |                                                       0 |
            +------+--------------------------+------------------------------+---------------------------------------------------------+
            4 rows in set (0.00 sec)
            

            On debug version with MyIsam and Innodb:

             Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))' fails in Field_long::val_int()
            

            after the query:

            select rank() over (order by c)  from (select 5 as c from t1) as dt;
            

            10.2 64900e3d7c3e5f3639cb

             
            #6  0x00007faf0d8b2bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x5582d8769e40 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))", file=file@entry=0x5582d8769bd8 "/10.2/sql/field.cc", line=line@entry=4332, function=function@entry=0x5582d876c900 <Field_long::val_int()::__PRETTY_FUNCTION__> "virtual longlong Field_long::val_int()") at assert.c:92
            #7  0x00007faf0d8b2c82 in __GI___assert_fail (assertion=0x5582d8769e40 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))", file=0x5582d8769bd8 "/10.2/sql/field.cc", line=4332, function=0x5582d876c900 <Field_long::val_int()::__PRETTY_FUNCTION__> "virtual longlong Field_long::val_int()") at assert.c:101
            #8  0x00005582d7e685d3 in Field_long::val_int (this=0x7faebc0751f8) at /10.2/sql/field.cc:4332
            #9  0x00005582d7eba603 in Item_ref::val_int_result (this=0x7faebc0150e0) at /10.2/sql/item.cc:7887
            #10 0x00005582d7e8bc77 in Type_handler_int_result::make_sort_key (this=0x5582d91ace18 <type_handler_longlong>, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/filesort.cc:1070
            #11 0x00005582d7b4be2b in Item::make_sort_key (this=0x7faebc0150e0, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/item.h:934
            #12 0x00005582d7e8c15d in make_sortkey (param=0x7faf000f1710, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", ref_pos=0x7faebc0753e0 "\200E\003\274\256\177") at /10.2/sql/filesort.cc:1187
            #13 0x00005582d7e8b321 in find_all_keys (thd=0x7faebc000b00, param=0x7faf000f1710, select=0x0, fs_info=0x7faebc075f60, buffpek_pointers=0x7faf000f1910, tempfile=0x7faf000f17a0, pq=0x0, found_rows=0x7faebc076140) at /10.2/sql/filesort.cc:862
            #14 0x00005582d7e895ce in filesort (thd=0x7faebc000b00, table=0x7faebc08bdf8, filesort=0x7faebc016f70, tracker=0x7faebc017138, join=0x7faebc014338, first_table_bit=1) at /10.2/sql/filesort.cc:279
            #15 0x00005582d7c89a48 in create_sort_index (thd=0x7faebc000b00, join=0x7faebc014338, tab=0x7faebc0161a8, fsort=0x7faebc016f70) at /10.2/sql/sql_select.cc:22022
            #16 0x00005582d7de018a in Window_funcs_sort::exec (this=0x7faebc016ea8, join=0x7faebc014338, keep_filesort_result=true) at /10.2/sql/sql_window.cc:2804
            #17 0x00005582d7de06d2 in Window_funcs_computation::exec (this=0x7faebc016e88, join=0x7faebc014338, keep_last_filesort_result=true) at /10.2/sql/sql_window.cc:2936
            #18 0x00005582d7c96ba6 in AGGR_OP::end_send (this=0x7faebc016e58) at /10.2/sql/sql_select.cc:26794
            #19 0x00005582d7c8189d in sub_select_postjoin_aggr (join=0x7faebc014338, join_tab=0x7faebc0161a8, end_of_records=true) at /10.2/sql/sql_select.cc:18537
            #20 0x00005582d7c81bc1 in sub_select (join=0x7faebc014338, join_tab=0x7faebc015df8, end_of_records=true) at /10.2/sql/sql_select.cc:18773
            #21 0x00005582d7c813d9 in do_select (join=0x7faebc014338, procedure=0x0) at /10.2/sql/sql_select.cc:18368
            #22 0x00005582d7c5b0ad in JOIN::exec_inner (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3626
            #23 0x00005582d7c5a55c in JOIN::exec (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3421
            #24 0x00005582d7c5b71e in mysql_select (thd=0x7faebc000b00, tables=0x7faebc013c30, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7faebc014318, unit=0x7faebc004700, select_lex=0x7faebc004e38) at /10.2/sql/sql_select.cc:3821
            #25 0x00005582d7c4f980 in handle_select (thd=0x7faebc000b00, lex=0x7faebc004638, result=0x7faebc014318, setup_tables_done_option=0) at /10.2/sql/sql_select.cc:377
            #26 0x00005582d7c1b056 in execute_sqlcom_select (thd=0x7faebc000b00, all_tables=0x7faebc013c30) at /10.2/sql/sql_parse.cc:6226
            #27 0x00005582d7c11a46 in mysql_execute_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:3533
            #28 0x00005582d7c1eee1 in mysql_parse (thd=0x7faebc000b00, rawbuf=0x7faebc012458 "select rank() over (order by c)  from (select 5 as c from t1) as dt", length=67, parser_state=0x7faf000f3080, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:7760
            #29 0x00005582d7c0d1aa in dispatch_command (command=COM_QUERY, thd=0x7faebc000b00, packet=0x7faebc0962c1 "", packet_length=67, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:1832
            #30 0x00005582d7c0babe in do_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:1386
            #31 0x00005582d7d60b0d in do_handle_one_connection (connect=0x5582dba99360) at /10.2/sql/sql_connect.cc:1336
            #32 0x00005582d7d60878 in handle_one_connection (arg=0x5582dba99360) at /10.2/sql/sql_connect.cc:1241
            #33 0x00005582d858ad94 in pfs_spawn_thread (arg=0x5582dbaa4150) at /10.2/storage/perfschema/pfs.cc:1862
            #34 0x00007faf0e4f76ba in start_thread (arg=0x7faf000f4700) at pthread_create.c:333
            #35 0x00007faf0d98c41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
            

            on 10.4 assertion was renamed to `marked_for_read()'

            alice Alice Sherepa added a comment - Thanks a lot for the report! Reproduced as described on 10.2-10.4: create table t1 (a int , b int ); insert into t1 values (4, -2), (3, -1);   select b, rank() over ( order by c) , rank() over ( order by dt1.b) from ( select 5 as c from t1) as dt, ( select b from t1) as dt1;   select b, rank() over ( order by c) , rank() over ( order by dt1.b), rank() over ( order by c) = rank() over ( order by dt1.b) from ( select 5 as c from t1) as dt, ( select b from t1) as dt1; on non-debug versions - wrong results: 10.2.24 MariaDB [test]> select b, rank() over (order by c) , rank() over (order by dt1.b) -> from -> (select 5 as c from t1) as dt, -> (select b from t1) as dt1; +------+--------------------------+------------------------------+ | b | rank() over (order by c) | rank() over (order by dt1.b) | +------+--------------------------+------------------------------+ | -2 | 1 | 1 | | -2 | 1 | 1 | | -1 | 1 | 3 | | -1 | 1 | 3 | +------+--------------------------+------------------------------+ 4 rows in set (0.00 sec)   MariaDB [test]> select b, rank() over (order by c) , rank() over (order by dt1.b), -> rank() over (order by c) = rank() over (order by dt1.b) -> from -> (select 5 as c from t1) as dt, -> (select b from t1) as dt1; +------+--------------------------+------------------------------+---------------------------------------------------------+ | b | rank() over (order by c) | rank() over (order by dt1.b) | rank() over (order by c) = rank() over (order by dt1.b) | +------+--------------------------+------------------------------+---------------------------------------------------------+ | -1 | 1 | 1 | 1 | | -2 | 1 | 2 | 0 | | -2 | 1 | 2 | 0 | | -1 | 1 | 4 | 0 | +------+--------------------------+------------------------------+---------------------------------------------------------+ 4 rows in set (0.00 sec) On debug version with MyIsam and Innodb: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))' fails in Field_long::val_int() after the query: select rank() over ( order by c) from ( select 5 as c from t1) as dt; 10.2 64900e3d7c3e5f3639cb   #6 0x00007faf0d8b2bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x5582d8769e40 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))", file=file@entry=0x5582d8769bd8 "/10.2/sql/field.cc", line=line@entry=4332, function=function@entry=0x5582d876c900 <Field_long::val_int()::__PRETTY_FUNCTION__> "virtual longlong Field_long::val_int()") at assert.c:92 #7 0x00007faf0d8b2c82 in __GI___assert_fail (assertion=0x5582d8769e40 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))", file=0x5582d8769bd8 "/10.2/sql/field.cc", line=4332, function=0x5582d876c900 <Field_long::val_int()::__PRETTY_FUNCTION__> "virtual longlong Field_long::val_int()") at assert.c:101 #8 0x00005582d7e685d3 in Field_long::val_int (this=0x7faebc0751f8) at /10.2/sql/field.cc:4332 #9 0x00005582d7eba603 in Item_ref::val_int_result (this=0x7faebc0150e0) at /10.2/sql/item.cc:7887 #10 0x00005582d7e8bc77 in Type_handler_int_result::make_sort_key (this=0x5582d91ace18 <type_handler_longlong>, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/filesort.cc:1070 #11 0x00005582d7b4be2b in Item::make_sort_key (this=0x7faebc0150e0, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/item.h:934 #12 0x00005582d7e8c15d in make_sortkey (param=0x7faf000f1710, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", ref_pos=0x7faebc0753e0 "\200E\003\274\256\177") at /10.2/sql/filesort.cc:1187 #13 0x00005582d7e8b321 in find_all_keys (thd=0x7faebc000b00, param=0x7faf000f1710, select=0x0, fs_info=0x7faebc075f60, buffpek_pointers=0x7faf000f1910, tempfile=0x7faf000f17a0, pq=0x0, found_rows=0x7faebc076140) at /10.2/sql/filesort.cc:862 #14 0x00005582d7e895ce in filesort (thd=0x7faebc000b00, table=0x7faebc08bdf8, filesort=0x7faebc016f70, tracker=0x7faebc017138, join=0x7faebc014338, first_table_bit=1) at /10.2/sql/filesort.cc:279 #15 0x00005582d7c89a48 in create_sort_index (thd=0x7faebc000b00, join=0x7faebc014338, tab=0x7faebc0161a8, fsort=0x7faebc016f70) at /10.2/sql/sql_select.cc:22022 #16 0x00005582d7de018a in Window_funcs_sort::exec (this=0x7faebc016ea8, join=0x7faebc014338, keep_filesort_result=true) at /10.2/sql/sql_window.cc:2804 #17 0x00005582d7de06d2 in Window_funcs_computation::exec (this=0x7faebc016e88, join=0x7faebc014338, keep_last_filesort_result=true) at /10.2/sql/sql_window.cc:2936 #18 0x00005582d7c96ba6 in AGGR_OP::end_send (this=0x7faebc016e58) at /10.2/sql/sql_select.cc:26794 #19 0x00005582d7c8189d in sub_select_postjoin_aggr (join=0x7faebc014338, join_tab=0x7faebc0161a8, end_of_records=true) at /10.2/sql/sql_select.cc:18537 #20 0x00005582d7c81bc1 in sub_select (join=0x7faebc014338, join_tab=0x7faebc015df8, end_of_records=true) at /10.2/sql/sql_select.cc:18773 #21 0x00005582d7c813d9 in do_select (join=0x7faebc014338, procedure=0x0) at /10.2/sql/sql_select.cc:18368 #22 0x00005582d7c5b0ad in JOIN::exec_inner (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3626 #23 0x00005582d7c5a55c in JOIN::exec (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3421 #24 0x00005582d7c5b71e in mysql_select (thd=0x7faebc000b00, tables=0x7faebc013c30, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7faebc014318, unit=0x7faebc004700, select_lex=0x7faebc004e38) at /10.2/sql/sql_select.cc:3821 #25 0x00005582d7c4f980 in handle_select (thd=0x7faebc000b00, lex=0x7faebc004638, result=0x7faebc014318, setup_tables_done_option=0) at /10.2/sql/sql_select.cc:377 #26 0x00005582d7c1b056 in execute_sqlcom_select (thd=0x7faebc000b00, all_tables=0x7faebc013c30) at /10.2/sql/sql_parse.cc:6226 #27 0x00005582d7c11a46 in mysql_execute_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:3533 #28 0x00005582d7c1eee1 in mysql_parse (thd=0x7faebc000b00, rawbuf=0x7faebc012458 "select rank() over (order by c) from (select 5 as c from t1) as dt", length=67, parser_state=0x7faf000f3080, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:7760 #29 0x00005582d7c0d1aa in dispatch_command (command=COM_QUERY, thd=0x7faebc000b00, packet=0x7faebc0962c1 "", packet_length=67, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:1832 #30 0x00005582d7c0babe in do_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:1386 #31 0x00005582d7d60b0d in do_handle_one_connection (connect=0x5582dba99360) at /10.2/sql/sql_connect.cc:1336 #32 0x00005582d7d60878 in handle_one_connection (arg=0x5582dba99360) at /10.2/sql/sql_connect.cc:1241 #33 0x00005582d858ad94 in pfs_spawn_thread (arg=0x5582dbaa4150) at /10.2/storage/perfschema/pfs.cc:1862 #34 0x00007faf0e4f76ba in start_thread (arg=0x7faf000f4700) at pthread_create.c:333 #35 0x00007faf0d98c41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 on 10.4 assertion was renamed to `marked_for_read()'

            Simplifying the problematic query:

            Using a view

            create view v1 as select 5 as c from t1;
            select b, rank() over (order by c) from v1;
            

            So the field c in the query is actually a constant.
            This crashes on an ASSERT because the bitmap read_set of the temp table
            is not set for c. The item c is an Item_direct_view_ref, which refers to the constant 5.

            For sorting on the temp table, in the function find_all_keys we use the
            bitmap tmp_set, initialize it and then call the function register_used_fields
            which sets read_set for the fields involved in
            sorting (both sort-key and addon fields).

            Inside this function when we come across the item c, the bitmap read_set is not
            set. There is no need because it is a constant item and for
            Item_direct_view_ref we need to get the
            value from the original item.

            But while running make_sortkey we call val_*_result, which tries to get the
            value from the temp table and then hits the assert. For Item_direct_view_ref
            items we need to get the value from the original item.

            So this should also be fixed by MDEV-20922.

            varun Varun Gupta (Inactive) added a comment - Simplifying the problematic query: Using a view create view v1 as select 5 as c from t1; select b, rank() over ( order by c) from v1; So the field c in the query is actually a constant. This crashes on an ASSERT because the bitmap read_set of the temp table is not set for c. The item c is an Item_direct_view_ref, which refers to the constant 5. For sorting on the temp table, in the function find_all_keys we use the bitmap tmp_set, initialize it and then call the function register_used_fields which sets read_set for the fields involved in sorting (both sort-key and addon fields). Inside this function when we come across the item c, the bitmap read_set is not set. There is no need because it is a constant item and for Item_direct_view_ref we need to get the value from the original item. But while running make_sortkey we call val_*_result, which tries to get the value from the temp table and then hits the assert. For Item_direct_view_ref items we need to get the value from the original item. So this should also be fixed by MDEV-20922 .
            alice Alice Sherepa added a comment -

            there is no assertion now on 10.3-10.10 (10.3 f4a1298f245f678badc8a5b5), but the results are still incorrect.

            alice Alice Sherepa added a comment - there is no assertion now on 10.3-10.10 (10.3 f4a1298f245f678badc8a5b5), but the results are still incorrect.

            Alice, it would have helped a lot if you could have printed what would be the correct results for your examples!

            monty Michael Widenius added a comment - Alice, it would have helped a lot if you could have printed what would be the correct results for your examples!

            Varun, your example does not work:
            mysqltest: At line 4044: query 'select b, rank() over (order by c) from v1' failed: 1054: Unknown column 'b' in 'field list'

            monty Michael Widenius added a comment - Varun, your example does not work: mysqltest: At line 4044: query 'select b, rank() over (order by c) from v1' failed: 1054: Unknown column 'b' in 'field list'

            The problematic query outlined a bug in window functions sorting
            optimization. When multiple window functions are present in a query,
            we sort the sorting key (as defined by PARTITION BY and ORDER BY) from
            generic to specific.

            SELECT RANK() OVER (ORDER BY const_col) as r1,
            RANK() OVER (ORDER BY const_col, a) as r2,
            RANK() OVER (PARTITION BY c) as r3,
            RANK() OVER (PARTITION BY c ORDER BY b) as r4
            FROM table;

            For these functions, the sorting we need to do for window function
            computations are: [(const_col), (const_col, a)] and [(c), (c, b)].

            Instead of doing 4 different sort order, the sorts grouped within [] are
            compatible and we can use the most specific sort to cover both window
            functions.

            The bug was caused by an incorrect flagging of which sort is most
            specific for a compatible group of functions. In our specific test case,
            instead of picking (const_col, a) as the most specific sort, it would
            only sort by (const_col), which lead to wrong results for rank function.
            By ensuring that we pick the last sort key before an "incompatible sort"
            flag is met in our "ordered array of sorting specifications", we
            guarantee correct results.

            monty Michael Widenius added a comment - The problematic query outlined a bug in window functions sorting optimization. When multiple window functions are present in a query, we sort the sorting key (as defined by PARTITION BY and ORDER BY) from generic to specific. SELECT RANK() OVER (ORDER BY const_col) as r1, RANK() OVER (ORDER BY const_col, a) as r2, RANK() OVER (PARTITION BY c) as r3, RANK() OVER (PARTITION BY c ORDER BY b) as r4 FROM table; For these functions, the sorting we need to do for window function computations are: [(const_col), (const_col, a)] and [(c), (c, b)] . Instead of doing 4 different sort order, the sorts grouped within [] are compatible and we can use the most specific sort to cover both window functions. The bug was caused by an incorrect flagging of which sort is most specific for a compatible group of functions. In our specific test case, instead of picking (const_col, a) as the most specific sort, it would only sort by (const_col), which lead to wrong results for rank function. By ensuring that we pick the last sort key before an "incompatible sort" flag is met in our "ordered array of sorting specifications", we guarantee correct results.

            Pushed to 10.4 tree

            monty Michael Widenius added a comment - Pushed to 10.4 tree

            People

              monty Michael Widenius
              Alicen -
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.