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

Implement FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK for views

Details

    Description

      FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK does not currently work for views.

      For example, if we have this view:

      CREATE TABLE t (qty INT, price INT);
      CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t;
      

      We can see this behavior:

      MariaDB [db1]> FLUSH TABLES v WITH READ LOCK;
      ERROR 1347 (HY000): 'db1.v' is not BASE TABLE
      

      However, LOCK TABLES ... READ is smart enough to lock the underlying tables:

      MariaDB [db1]> LOCK TABLES v READ;
      Query OK, 0 rows affected (0.00 sec)
      

      Some users would like to see FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK work similarly for views.

      Attachments

        Issue Links

          Activity

            FLUSH TABLE v works for views, and LOCK TABLES v READ works for views. One can expect FLUSH TABLE v WITH READ LOCK to work too.

            serg Sergei Golubchik added a comment - FLUSH TABLE v works for views, and LOCK TABLES v READ works for views. One can expect FLUSH TABLE v WITH READ LOCK to work too.
            holyfoot Alexey Botchkov added a comment - http://lists.askmonty.org/pipermail/commits/2018-October/013042.html

            holyfoot, relevant code have changed in all major versions, which means we have to have like 5 different implementations.

            According to Rasmus there's no strong need to have it in GA versions. So, let's retarget for 10.4.

            In 10.4 we should call extra(HA_EXTRA_FLUSH) instead of closing tables.

            Also I'm not sure if blocking commits is really needed here. If not, instead of taking BACKUP locks, we should probably take MDL_SHARED_READ_ONLY in TABLE namespace.

            svoj Sergey Vojtovich added a comment - holyfoot , relevant code have changed in all major versions, which means we have to have like 5 different implementations. According to Rasmus there's no strong need to have it in GA versions. So, let's retarget for 10.4. In 10.4 we should call extra(HA_EXTRA_FLUSH) instead of closing tables. Also I'm not sure if blocking commits is really needed here. If not, instead of taking BACKUP locks, we should probably take MDL_SHARED_READ_ONLY in TABLE namespace.

            I tried to adapt the previous solution for this issue - to collect all the related tables in one list to do the first lock_table_names(SNR) lock.
            But then i noticed it wasn't necessary. Couldn't find the testcase that fails without that locking so tried to just remove that code.The test suite didn't fail after it so now i need your comment/suggestion on this experimental solution patch.
            https://github.com/MariaDB/server/commit/308c28e8a60ed3cbeb33db9154764142d7931923

            holyfoot Alexey Botchkov added a comment - I tried to adapt the previous solution for this issue - to collect all the related tables in one list to do the first lock_table_names(SNR) lock. But then i noticed it wasn't necessary. Couldn't find the testcase that fails without that locking so tried to just remove that code.The test suite didn't fail after it so now i need your comment/suggestion on this experimental solution patch. https://github.com/MariaDB/server/commit/308c28e8a60ed3cbeb33db9154764142d7931923
            holyfoot Alexey Botchkov added a comment - https://github.com/MariaDB/server/commit/a40a36d9b9dc8b78171214905dce6d7fe19961d7

            a40a36d9b9dc is ok to push

            serg Sergei Golubchik added a comment - a40a36d9b9dc is ok to push
            holyfoot Alexey Botchkov added a comment - https://github.com/MariaDB/server/commit/b118f92be6b8d7294f3b57f824559ced3dcccc6b

            People

              holyfoot Alexey Botchkov
              GeoffMontee Geoff Montee (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              8 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.