As far as the documentation goes, it's accurate, as they have two different names, and one is the Percona XtraDB implementation, and the other MySQL 5.7's. I may eventually merge them depending on what happens in later versions of 10.2 XtraDB. As far as the internals and whether the MySQL bug also applies, I don't know, so will leave this for someone else to investigate.

Great that you are investigating this!

I've seen quite often that people have contention in adaptive hash index mutexes. In the PS meeting there were some thoughts of disabling it as a precaution, because the benefit may not weigh up against the contention. After fixing this we may want to benchmark it's benefits/drawback and reevaluate.

If you use INFORMATION_SCHEMA.SYSTEM_VARIABLES on 10.2, it will tell you the whole story.

MariaDB [test]> select * from information_schema.system_variables where variable_name like 'innodb_adaptive_hash_index_par%' \G

*************************** 1. row ***************************

        VARIABLE_NAME: INNODB_ADAPTIVE_HASH_INDEX_PARTS

        SESSION_VALUE: NULL

         GLOBAL_VALUE: 8

  GLOBAL_VALUE_ORIGIN: COMPILE-TIME

        DEFAULT_VALUE: 8

       VARIABLE_SCOPE: GLOBAL

        VARIABLE_TYPE: BIGINT UNSIGNED

     VARIABLE_COMMENT: Number of InnoDB Adaptive Hash Index Partitions (default 8)

    NUMERIC_MIN_VALUE: 1

    NUMERIC_MAX_VALUE: 512

   NUMERIC_BLOCK_SIZE: 0

      ENUM_VALUE_LIST: NULL

            READ_ONLY: YES

COMMAND_LINE_ARGUMENT: OPTIONAL

*************************** 2. row ***************************

        VARIABLE_NAME: INNODB_ADAPTIVE_HASH_INDEX_PARTITIONS

        SESSION_VALUE: NULL

         GLOBAL_VALUE: 8

  GLOBAL_VALUE_ORIGIN: COMPILE-TIME

        DEFAULT_VALUE: 8

       VARIABLE_SCOPE: GLOBAL

        VARIABLE_TYPE: BIGINT UNSIGNED

     VARIABLE_COMMENT: It is an alias for innodb_adaptive_hash_index_parts; only exists to allow easier upgrade from earlier XtraDB versions.

    NUMERIC_MIN_VALUE: 1

    NUMERIC_MAX_VALUE: 512

   NUMERIC_BLOCK_SIZE: 0

      ENUM_VALUE_LIST: NULL

            READ_ONLY: YES

COMMAND_LINE_ARGUMENT: OPTIONAL

2 rows in set (0.00 sec)

For the second question, about an upstream bug report, it's unrelated to the reported documentation question, so if there anything to do about it, please create a separate bug report. However, please note that whether it applies to 5.5 (or to anything below 10.2) has become rather theoretical question after 10.2 became GA.

greenman, do you think it's worth mentioning in the description that in 10.2 one is an alias for another?

This was documented, and now that 10.2 is stable and the one set as an alias of other there should be no further changes. Will close this documentation bug - the upstream issue can be reported separately.