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

ha_innobase::open() should not acquire dict_sys.latch twice

Details

    Description

      The following stack trace had to wait on dict_sys.latch:

      ssux_lock_impl<false>::rd_wait()
      		 
      dict_table_open_on_name(char const*, bool, dict_err_ignore_t)
      		 
      dict_stats_update(dict_table_t*, dict_stats_upd_option_t)
      		 
      ha_innobase::info_low(unsigned int, bool)
      		 
      ha_innobase::open(char const*, int, unsigned int)
      		 
      handler::ha_open(TABLE*, char const*, int, unsigned int, st_mem_root*, List<String>*)

      (According to Marko Mäkelä: ) This one is an InnoDB bug. We certainly should not acquire and release a shared dict_sys.latch within a single ha_innobase::open().

      Attachments

        Issue Links

          blocks

          Task - A task that needs to be done. MDEV-34986 Use RAII classes to manage locks

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • In Review
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-35000 dict_table_close() breaks innodb_stats_auto_recalc

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-35154 dict_sys_t::load_table() is holding exclusive dict_sys.latch for unnecessarily long time

          • Major - Major loss of function.
          • Confirmed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-35436 dict_stats_fetch_from_ps() unnecessarily holds exclusive dict_sys.latch

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-34988 InnoDB locks dict_sys.latch for a long time during ALTER TABLE

          • Major - Major loss of function.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            marko Marko Mäkelä added a comment -

            My point was that one dict_sys.latch acquisition earlier during ha_innobase::open() is unavoidable.

            The acquisition in dict_stats_update() could be entirely redundant, because the callers from the SQL layer should be holding a metadata lock and a reference count on the table. Also the background task that executes dict_stats_process_entry_from_recalc_pool() will acquire both a metadata lock and a reference on the table that it is processing.

            marko Marko Mäkelä added a comment - My point was that one dict_sys.latch acquisition earlier during ha_innobase::open() is unavoidable. The acquisition in dict_stats_update() could be entirely redundant, because the callers from the SQL layer should be holding a metadata lock and a reference count on the table. Also the background task that executes dict_stats_process_entry_from_recalc_pool() will acquire both a metadata lock and a reference on the table that it is processing.
            marko Marko Mäkelä added a comment -

            Unless the table was created with STATS_PERSISTENT=0 or the server is running with innodb_stats_persistent=OFF, then as noted in MDEV-35436, InnoDB would acquire and release a shared dict_sys.latch a couple more times while preparing to fetch the persistent statistics, and unnecessarily holding an exclusive dict_sys.latch while fetching the statistics (and possibly being blocked by the buffer pool).

            MDEV-35154 describes how the critical section of dict_sys.latch could be reduced so that it would never cover I/O waits.

            marko Marko Mäkelä added a comment - Unless the table was created with STATS_PERSISTENT=0 or the server is running with innodb_stats_persistent=OFF , then as noted in MDEV-35436 , InnoDB would acquire and release a shared dict_sys.latch a couple more times while preparing to fetch the persistent statistics, and unnecessarily holding an exclusive dict_sys.latch while fetching the statistics (and possibly being blocked by the buffer pool). MDEV-35154 describes how the critical section of dict_sys.latch could be reduced so that it would never cover I/O waits.

            People

              marko Marko Mäkelä
              maxk Max Kellermann
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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