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

FTRWL and FLUSH .. FOR EXPORT on TEMPTABLE view take too weak locks on underlying tables

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.6
    • 10.6
    • Locking, Views
    • None

    Description

      FTWRL and FLUSH FOR EXPORT on views, implemented in the scope of MDEV-15888, don't ensure that underlying tables cannot be written to. Given the specifics of the operations, especially FOR EXPORT, it seems to be pointless to lock only the view from updates.

      --source include/have_metadata_lock_info.inc
      		 
       
      		 
      --connect(con1,localhost,root,,)
      		 
      SET lock_wait_timeout= 0;
      		 
       
      		 
      --connection default
      		 
      CREATE TABLE t (a INT);
      		 
      CREATE ALGORITHM=TEMPTABLE VIEW v AS SELECT * FROM t;
      		 
       
      		 
      FLUSH TABLE v WITH READ LOCK;
      		 
      SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO;
      		 
       
      		 
      --connection con1
      		 
      INSERT INTO t VALUES (1);
      		 
       
      		 
      --connection default
      		 
      UNLOCK TABLES;
      		 
       
      		 
      FLUSH TABLE v FOR EXPORT;
      		 
      SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO;
      		 
       
      		 
      --connection con1
      		 
      INSERT INTO t VALUES (1);
      		 
       
      		 
      --connection default
      		 
      UNLOCK TABLES;
      		 
       
      		 
      # Cleanup
      		 
      DROP VIEW v;
      		 
      DROP TABLE t;

      10.6 59bc063d

      		 
      FLUSH TABLE v WITH READ LOCK;
      		 
      SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO;
      		 
      THREAD_ID	LOCK_MODE	LOCK_DURATION	LOCK_TYPE	TABLE_SCHEMA	TABLE_NAME
      		 
      4	MDL_SHARED_NO_WRITE	NULL	Table metadata lock	test	v
      		 
      4	MDL_SHARED_READ	NULL	Table metadata lock	test	t
      		 
      connection con1;
      		 
      INSERT INTO t VALUES (1);
      		 
      connection default;
      		 
      UNLOCK TABLES;
      		 
      FLUSH TABLE v FOR EXPORT;
      		 
      SELECT * FROM INFORMATION_SCHEMA.METADATA_LOCK_INFO;
      		 
      THREAD_ID	LOCK_MODE	LOCK_DURATION	LOCK_TYPE	TABLE_SCHEMA	TABLE_NAME
      		 
      4	MDL_SHARED_NO_WRITE	NULL	Table metadata lock	test	v
      		 
      4	MDL_SHARED_READ	NULL	Table metadata lock	test	t
      		 
      connection con1;
      		 
      INSERT INTO t VALUES (1);
      		 
      connection default;
      		 
      UNLOCK TABLES;

      So, in both cases it only takes MDL_SHARED_READ on the table which allows updates, while the same FLUSH performed on the table directly (or on a merge view) takes MDL_SHARED_NO_WRITE.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26087 InnoDB: Failing assertion: table->quiesce == QUIESCE_START upon concurrent FLUSH on view

          • Major - Major loss of function.
          • Confirmed

          Task - A task that needs to be done. MDEV-15888 Implement FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK for views

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            People

              serg Sergei Golubchik
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              1 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.