I don't see a bug here.

• FLUSH TABLE requires write lock since 5.5. This is intentional.
• The error message is not wrong, table 'v' was not locked with LOCK TABLES, indeed. Even view wasn't, LOCK TABLES v locks the underlying table t.

For the record, I agree with GeoffMontee that the error message is wrong in the sense that it's confusing and normal-user-unfriendly, even if it's factually correct. For example, ER_IT_IS_A_VIEW would make much more sense, and probably we have more of the kind.

Also, FWIW, while a table v of course wasn't locked here, the view v actually was:

MariaDB [test]> lock tables v read;

Query OK, 0 rows affected (0.00 sec)

MariaDB [test]> select * from information_schema.metadata_lock_info;

+-----------+----------------------+---------------+---------------------+--------------+------------+

| THREAD_ID | LOCK_MODE            | LOCK_DURATION | LOCK_TYPE           | TABLE_SCHEMA | TABLE_NAME |

+-----------+----------------------+---------------+---------------------+--------------+------------+

|         9 | MDL_SHARED_READ      | NULL          | Table metadata lock | test         | v          |

|         9 | MDL_SHARED_READ_ONLY | NULL          | Table metadata lock | test         | t          |

+-----------+----------------------+---------------+---------------------+--------------+------------+

2 rows in set (0.00 sec)

LOCK TABLE puts read/write table locks, not only metadata locks. See SHOW OPEN TABLES. And there is no way to put a table lock on a view.

On the other hand, if LOCK TABLES locks view's tables, perhaps FLUSH TABLES should check whether view's tables were locked, not whether the view itself was locked?

After all FLUSH TABLES also flushes tables and not the view itself.

Let's see if it's possible to get rid of this “strange” error message completely by allowing FLUSH TABLES v to work under LOCK TABLES v.

http://lists.askmonty.org/pipermail/commits/2018-June/012606.html

From Sergei's review:
------------------------------------------------------
That's a pretty neat solution

But it seems that - contrary to what I expected - that MariaDB actually
distinguishes between locking a view a locking all its tables. Consider
this test case:

create table t1 (a int);
create view v1 as select * from t1;
lock table v1 write;
insert v1 values (1);
select * from t1;
unlock tables;
drop view v1;
drop table t1;

this works and inserts 1 just fine. If you change the lock table
statement to lock t1, it'll with

Table 'v1' was not locked with LOCK TABLES

It'd be great if FLUSH TABLES will exhibit the same behavior, it needs
to know if the view is locked, not only if all underlying tables are
locked.
----------------------------------------------------

Fix proposal v2
http://lists.askmonty.org/pipermail/commits/2018-June/012645.html

http://lists.askmonty.org/pipermail/commits/2018-September/012870.html

http://lists.askmonty.org/pipermail/commits/2018-September/012873.html

http://lists.askmonty.org/pipermail/commits/2018-September/012905.html

ok to push