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

Assertion `user_table->get_ref_count() == 1' failed upon OPTIMIZE on statistical table

Details

    Description

      The test case is non-deterministic, needs to be run with --repeat=N. It usually fails for me within several dozen attempts. The test case is rr-rable.

      --source include/have_innodb.inc
       
      CREATE TABLE t (
        pk INT AUTO_INCREMENT,
        a INT,
        b DATETIME,
        c VARCHAR(1),
        PRIMARY KEY (pk ASC),
        KEY (a DESC),
        KEY (b ASC),
        KEY (c DESC, a ASC)
      ) ENGINE=InnoDB STATS_PERSISTENT=1;
       
      --connect (con1,localhost,root,,)
      --connect (con2,localhost,root,,)
      --send
      	OPTIMIZE TABLE t;
      --connection con1
      OPTIMIZE TABLE mysql.innodb_index_stats;
      --connection default
      OPTIMIZE TABLE mysql.innodb_index_stats;
       
      DROP TABLE t;
      

      10.5 8778a83eee9472fe15da185a188543595f262cda

      mariadbd: /data/MDEV-33547/10.5/storage/innobase/handler/handler0alter.cc:10204: bool commit_try_rebuild(Alter_inplace_info*, ha_innobase_inplace_ctx*, TABLE*, const TABLE*, trx_t*, const char*): Assertion `user_table->get_ref_count() == 1' failed.
      (rr) bt
      #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
      #1  0x000004b612404859 in __GI_abort () at abort.c:79
      #2  0x000004b612404729 in __assert_fail_base (fmt=0x4b61259a588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x558f7f5d6c00 "user_table->get_ref_count() == 1", 
          file=0x558f7f5d20b8 "/data/MDEV-33547/10.5/storage/innobase/handler/handler0alter.cc", line=10204, function=<optimized out>) at assert.c:92
      #3  0x000004b612415fd6 in __GI___assert_fail (assertion=0x558f7f5d6c00 "user_table->get_ref_count() == 1", file=0x558f7f5d20b8 "/data/MDEV-33547/10.5/storage/innobase/handler/handler0alter.cc", 
          line=10204, function=0x558f7f5d9318 "bool commit_try_rebuild(Alter_inplace_info*, ha_innobase_inplace_ctx*, TABLE*, const TABLE*, trx_t*, const char*)") at assert.c:101
      #4  0x0000558f7ec94955 in commit_try_rebuild (ha_alter_info=0x33021489f600, ctx=0x366520020ca0, altered_table=0x33021489f6a0, old_table=0x366520025578, trx=0x671338814468, 
          table_name=0x70b6400f725e "innodb_index_stats") at /data/MDEV-33547/10.5/storage/innobase/handler/handler0alter.cc:10204
      #5  0x0000558f7ec82f3a in ha_innobase::commit_inplace_alter_table (this=0x366520025da0, altered_table=0x33021489f6a0, ha_alter_info=0x33021489f600, commit=true)
          at /data/MDEV-33547/10.5/storage/innobase/handler/handler0alter.cc:11313
      #6  0x0000558f7e8cbb60 in handler::ha_commit_inplace_alter_table (this=0x366520025da0, altered_table=0x33021489f6a0, ha_alter_info=0x33021489f600, commit=true) at /data/MDEV-33547/10.5/sql/handler.cc:4951
      #7  0x0000558f7e66c69e in mysql_inplace_alter_table (thd=0x36652000c968, table_list=0x36652001e618, table=0x366520025578, altered_table=0x33021489f6a0, ha_alter_info=0x33021489f600, 
          target_mdl_request=0x33021489fa90, alter_ctx=0x3302148a05e0) at /data/MDEV-33547/10.5/sql/sql_table.cc:8295
      #8  0x0000558f7e674dd7 in mysql_alter_table (thd=0x36652000c968, new_db=0x558f7f3594f0 <null_clex_str>, new_name=0x558f7f3594f0 <null_clex_str>, create_info=0x3302148a11d0, table_list=0x36652001e618, 
          recreate_info=0x3302148a15b0, alter_info=0x3302148a10e0, order_num=0, order=0x0, ignore=false, if_exists=false) at /data/MDEV-33547/10.5/sql/sql_table.cc:11031
      #9  0x0000558f7e67822c in mysql_recreate_table (thd=0x36652000c968, table_list=0x36652001e618, recreate_info=0x3302148a15b0, table_copy=false) at /data/MDEV-33547/10.5/sql/sql_table.cc:11995
      #10 0x0000558f7e71d3c4 in admin_recreate_table (thd=0x36652000c968, table_list=0x36652001e618, recreate_info=0x3302148a15b0) at /data/MDEV-33547/10.5/sql/sql_admin.cc:65
      #11 0x0000558f7e720764 in mysql_admin_table (thd=0x36652000c968, tables=0x36652001e618, check_opt=0x366520011c48, operator_name=0x558f7f3ac00e "optimize", lock_type=TL_WRITE, org_open_for_modify=true, 
          repair_table_use_frm=false, extra_open_options=0, prepare_func=0x0, operator_func=
          (int (handler::*)(class handler * const, class THD *, HA_CHECK_OPT *)) 0x558f7e8cb3bc <handler::ha_optimize(THD*, st_ha_check_opt*)>, view_operator_func=0x0, is_cmd_replicated=true)
          at /data/MDEV-33547/10.5/sql/sql_admin.cc:1148
      #12 0x0000558f7e721ae6 in Sql_cmd_optimize_table::execute (this=0x36652001ed18, thd=0x36652000c968) at /data/MDEV-33547/10.5/sql/sql_admin.cc:1513
      #13 0x0000558f7e57c040 in mysql_execute_command (thd=0x36652000c968) at /data/MDEV-33547/10.5/sql/sql_parse.cc:6159
      #14 0x0000558f7e581c25 in mysql_parse (thd=0x36652000c968, rawbuf=0x36652001e510 "OPTIMIZE TABLE mysql.innodb_index_stats", length=39, parser_state=0x3302148a2390, is_com_multi=false, 
          is_next_command=false) at /data/MDEV-33547/10.5/sql/sql_parse.cc:8196
      #15 0x0000558f7e56e2e1 in dispatch_command (command=COM_QUERY, thd=0x36652000c968, packet=0x366520016009 "", packet_length=39, is_com_multi=false, is_next_command=false)
          at /data/MDEV-33547/10.5/sql/sql_parse.cc:1891
      #16 0x0000558f7e56cdd2 in do_command (thd=0x36652000c968) at /data/MDEV-33547/10.5/sql/sql_parse.cc:1375
      #17 0x0000558f7e70946e in do_handle_one_connection (connect=0x558f81199178, put_in_cache=true) at /data/MDEV-33547/10.5/sql/sql_connect.cc:1415
      #18 0x0000558f7e709201 in handle_one_connection (arg=0x558f81199178) at /data/MDEV-33547/10.5/sql/sql_connect.cc:1317
      #19 0x00005ed0176c4609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #20 0x000004b612501133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      I have no information whether it's reproducible on other versions, at least I couldn't reproduce it with the provided test case on 10.6.

      Attachments

        Issue Links

          Activity

            In the rr replay trace that I checked, two offending references on the table mysql.innodb_index_stats are being held by another thread that is executing dict_stats_update() during OPTIMIZE TABLE t. We are lucky that the server is not hanging here (MDEV-15020).

            In MariaDB Server 10.6, the operations around the InnoDB statistics tables were rewritten to be properly protected by metadata locks (MDL). Any access to the statistics tables would be covered by a shared lock. That is, the OPTIMIZE TABLE t should be unable to access the persistent statistics while a DDL operation on one of the statistics tables is in a critical section.

            I do not think that this is fixable in MariaDB Server 10.5 or earlier versions. I would assume that bugs like this are not reproducible in 10.6 or later. Are they (now that MDEV-33462 has been fixed)?

            marko Marko Mäkelä added a comment - In the rr replay trace that I checked, two offending references on the table mysql.innodb_index_stats are being held by another thread that is executing dict_stats_update() during OPTIMIZE TABLE t . We are lucky that the server is not hanging here ( MDEV-15020 ). In MariaDB Server 10.6, the operations around the InnoDB statistics tables were rewritten to be properly protected by metadata locks (MDL). Any access to the statistics tables would be covered by a shared lock. That is, the OPTIMIZE TABLE t should be unable to access the persistent statistics while a DDL operation on one of the statistics tables is in a critical section. I do not think that this is fixable in MariaDB Server 10.5 or earlier versions. I would assume that bugs like this are not reproducible in 10.6 or later. Are they (now that MDEV-33462 has been fixed)?

            Similar to MDEV-15020, I don’t think that it is feasible to fix this in earlier major versions.

            marko Marko Mäkelä added a comment - Similar to MDEV-15020 , I don’t think that it is feasible to fix this in earlier major versions.

            It turns out that there is a problem on 10.6 after all. Filed as MDEV-33575.

            elenst Elena Stepanova added a comment - It turns out that there is a problem on 10.6 after all. Filed as MDEV-33575 .

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 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.