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

LP:677407 - Stale data in INFORMATION_SCHEMA.INNODB_LOCKS

    Details

      Description

      This is MySQL Bug#48883 (http://bugs.mysql.com/bug.php?id=48883).

      The XtraDB INFORMATION_SCHEMA.INNODB_PLUGIN table is populated in a two-step
      procedure. First, a table cache is filled with the real information, under the
      kernel_mutex. This is only done if at least 100 milliseconds has passed since
      last filling the cache. Second, the MySQL table data is populated from the
      cache, which may thus be up to 100 milliseconds old.

      There is a bug in the accounting for how often to do the first step. The
      timestamp for last update is updated in step 2, not in step 1. This has two
      consequences:

      1. If the INNODB_PLUGIN table is queried very frequently repeatedly (with less
      than 100 milliseconds interval in-between), stale data can be returned
      indefinitely, as the "last updated" timestamp is reset even though step 1 is
      not run. This is the problem seen in Bug#48883, and in MariaDB Buildbot.

      2. If multiple queries against INNODB_PLUGIN start at around the same time,
      they can all cause the cache to be updated, as the "last updated" timestamp
      is not reset immediately after updating the cache. This can cause extra
      unnecessary contention on kernel_mutex.

      The failure is easy to repeat by changing the sleep in
      mysql-test/include/wait_condition.inc from 0.1 to 0.01 seconds, and running
      the innodb_information_schema.test.

      I will attach a patch that fixes it.

        Attachments

          Activity

            People

            • Assignee:
              knielsen Kristian Nielsen
              Reporter:
              knielsen Kristian Nielsen
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: