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

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 10.6
    • Fix Version/s: 10.6
    • Component/s: Locking, Views
    • Labels:
      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

            Activity

              People

              Assignee:
              serg Sergei Golubchik
              Reporter:
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:

                  Git Integration