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

main.mdl_sync extra test.t2 row in I_S.metadata_lock_info

Details

    Description

      Test failure:

      main.mdl_sync                            w3 [ fail ]
              Test ended at 2025-04-19 06:40:48
      CURRENT_TEST: main.mdl_sync
      Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown option '--loose-disable-ssl-verify-server-cert'
      Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown variable 'loose-ssl-ca=/home/buildbot/amd64-debian-12-debug-embedded/build/mysql-test/std_data/cacert.pem'
      Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown variable 'loose-ssl-cert=/home/buildbot/amd64-debian-12-debug-embedded/build/mysql-test/std_data/client-cert.pem'
      Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown variable 'loose-ssl-key=/home/buildbot/amd64-debian-12-debug-embedded/build/mysql-test/std_data/client-key.pem'
      Warning: /home/buildbot/amd64-debian-12-debug-embedded/build/libmysqld/examples/mariadb-test-embedded: unknown option '--loose-skip-ssl'
      Got ERROR: "Failed to write to mysql.general_log: Wait on a lock was aborted due to a pending exclusive lock" errno: 2000
      --- /home/buildbot/amd64-debian-12-debug-embedded/build/mysql-test/main/mdl_sync.result	2025-04-19 06:35:23.000000000 +0000
      +++ /home/buildbot/amd64-debian-12-debug-embedded/build/mysql-test/main/mdl_sync.reject	2025-04-19 06:40:47.527987500 +0000
      @@ -2459,6 +2459,7 @@
       SELECT LOCK_MODE, LOCK_TYPE, TABLE_SCHEMA, TABLE_NAME FROM information_schema.metadata_lock_info;
       LOCK_MODE	LOCK_TYPE	TABLE_SCHEMA	TABLE_NAME
       MDL_BACKUP_FTWRL2	Backup lock		
      +MDL_SHARED	Table metadata lock	test	t2
       unlock tables;
       connection default;
       # Reaping UPDATE
      

      Another variant of this failure (--ps-protocol):

      mysqltest: At line 3161: The result of the 1st execution does not match with 
      the result of the 2nd execution of ps-protocol:
       1st:
      LOCK_MODE	LOCK_TYPE	TABLE_SCHEMA	TABLE_NAME
      MDL_BACKUP_FTWRL2	Backup lock		
      MDL_SHARED	Table metadata lock	test	t2
       
       2nd:
       LOCK_MODE	LOCK_TYPE	TABLE_SCHEMA	TABLE_NAME
      MDL_BACKUP_FTWRL2	Backup lock		
      

      Reported basing on this build.
      Cross reference shows more failures.

      Attachments

        Issue Links

          Activity

            Some unsuccessful attempts to get it fixed:

            commit e996f77cd8716320dc132bd63a252a4b5bb1366e
            Author: Thirunarayanan Balathandayuthapani <thiru@mariadb.com>
            Date:   Wed Nov 29 17:43:40 2023 +0530
             
                MDEV-32897  main suite test case prints extra row for metadata_lock_info query
             
                - Added the parameter stats_persistent=0 for InnoDB engine.
                - Before printing metadata_lock_info query, make sure that
                InnoDB does complete purging.
             
                Reviewed by: Marko Mäkelä
             
            commit a7bf0a42d0c1a5540c0b32a8284c1462d7c8c9a8
            Author: Sergei Golubchik <serg@mariadb.org>
            Date:   Sat Apr 6 23:05:57 2024 +0200
             
                sporadic failures of main.mdl_sync
             
                main.mdl_sync 'innodb'                   w32 [ fail ]
                        Test ended at 2024-04-06 14:11:15
             
                CURRENT_TEST: main.mdl_sync
                --- main/mdl_sync.result
                +++ main/mdl_sync.reject
                @@ -2458,6 +2458,7 @@
                 SELECT LOCK_MODE, LOCK_TYPE, TABLE_SCHEMA, TABLE_NAME FROM information_schema.metadata_lock_info;
                 LOCK_MODE      LOCK_TYPE       TABLE_SCHEMA    TABLE_NAME
                 MDL_BACKUP_FTWRL2      Backup lock
                +MDL_SHARED     Table metadata lock     test    t2
                 unlock tables;
                 connection default;
                 # Reaping UPDATE
            

            svoj Sergey Vojtovich added a comment - Some unsuccessful attempts to get it fixed: commit e996f77cd8716320dc132bd63a252a4b5bb1366e Author: Thirunarayanan Balathandayuthapani <thiru@mariadb.com> Date: Wed Nov 29 17:43:40 2023 +0530   MDEV-32897 main suite test case prints extra row for metadata_lock_info query   - Added the parameter stats_persistent=0 for InnoDB engine. - Before printing metadata_lock_info query, make sure that InnoDB does complete purging.   Reviewed by: Marko Mäkelä   commit a7bf0a42d0c1a5540c0b32a8284c1462d7c8c9a8 Author: Sergei Golubchik <serg@mariadb.org> Date: Sat Apr 6 23:05:57 2024 +0200   sporadic failures of main.mdl_sync   main.mdl_sync 'innodb' w32 [ fail ] Test ended at 2024-04-06 14:11:15   CURRENT_TEST: main.mdl_sync --- main/mdl_sync.result +++ main/mdl_sync.reject @@ -2458,6 +2458,7 @@ SELECT LOCK_MODE, LOCK_TYPE, TABLE_SCHEMA, TABLE_NAME FROM information_schema.metadata_lock_info; LOCK_MODE LOCK_TYPE TABLE_SCHEMA TABLE_NAME MDL_BACKUP_FTWRL2 Backup lock +MDL_SHARED Table metadata lock test t2 unlock tables; connection default; # Reaping UPDATE

            Consistently reproducible with this patch:

            diff --git a/mysql-test/main/mdl_sync.test b/mysql-test/main/mdl_sync.test
            index 29d95460d16..417bce051f4 100644
            --- a/mysql-test/main/mdl_sync.test
            +++ b/mysql-test/main/mdl_sync.test
            @@ -3156,6 +3156,7 @@ FLUSH TABLES WITH READ LOCK;
             
             let $wait_condition= SELECT COUNT(*)=1 FROM information_schema.metadata_lock_info;
             --source include/wait_condition.inc
            +--sleep 2
             SELECT LOCK_MODE, LOCK_TYPE, TABLE_SCHEMA, TABLE_NAME FROM information_schema.metadata_lock_info;
             
             unlock tables;
            diff --git a/storage/innobase/trx/trx0purge.cc b/storage/innobase/trx/trx0purge.cc
            index 0b9b5e3951c..99c67b7b863 100644
            --- a/storage/innobase/trx/trx0purge.cc
            +++ b/storage/innobase/trx/trx0purge.cc
            @@ -1116,6 +1116,7 @@ static dict_table_t *trx_purge_table_acquire(dict_table_t *table,
               char tbl_buf[NAME_LEN + 1];
               size_t tbl_len;
             
            +  sleep(1);
               if (!table->parse_name<true>(db_buf, tbl_buf, &db_len, &tbl_len))
                 /* The name of an intermediate table starts with #sql */
                 goto got_table;
            @@ -1129,6 +1130,7 @@ static dict_table_t *trx_purge_table_acquire(dict_table_t *table,
                 *mdl= request.ticket;
                 if (!*mdl)
                   goto must_wait;
            +    sleep(2);
               }
             
               goto got_table;
            

            At the very least it means purge still may fail this test.

            svoj Sergey Vojtovich added a comment - Consistently reproducible with this patch: diff --git a/mysql-test/main/mdl_sync.test b/mysql-test/main/mdl_sync.test index 29d95460d16..417bce051f4 100644 --- a/mysql-test/main/mdl_sync.test +++ b/mysql-test/main/mdl_sync.test @@ -3156,6 +3156,7 @@ FLUSH TABLES WITH READ LOCK;   let $wait_condition= SELECT COUNT(*)=1 FROM information_schema.metadata_lock_info; --source include/wait_condition.inc +--sleep 2 SELECT LOCK_MODE, LOCK_TYPE, TABLE_SCHEMA, TABLE_NAME FROM information_schema.metadata_lock_info;   unlock tables; diff --git a/storage/innobase/trx/trx0purge.cc b/storage/innobase/trx/trx0purge.cc index 0b9b5e3951c..99c67b7b863 100644 --- a/storage/innobase/trx/trx0purge.cc +++ b/storage/innobase/trx/trx0purge.cc @@ -1116,6 +1116,7 @@ static dict_table_t *trx_purge_table_acquire(dict_table_t *table, char tbl_buf[NAME_LEN + 1]; size_t tbl_len;   + sleep(1); if (!table->parse_name<true>(db_buf, tbl_buf, &db_len, &tbl_len)) /* The name of an intermediate table starts with #sql */ goto got_table; @@ -1129,6 +1130,7 @@ static dict_table_t *trx_purge_table_acquire(dict_table_t *table, *mdl= request.ticket; if (!*mdl) goto must_wait; + sleep(2); }   goto got_table; At the very least it means purge still may fail this test.

            People

              svoj Sergey Vojtovich
              svoj Sergey Vojtovich
              Votes:
              0 Vote for this issue
              Watchers:
              1 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.