Hi, Alexey!

On Jun 11, Alexey Botchkov wrote:
> revision-id: 20f347974f6a9b4e2c65a5ca79aefb8e118ba6cd 
> (mariadb-10.1.33-33-g20f3479)
> parent(s): 3627dd7f6a1cf5bd7151ff23290d64cb6dffea90
> committer: Alexey Botchkov
> timestamp: 2018-06-11 14:58:46 +0400
> message:
> MDEV-15890 Strange error message if you try to FLUSH TABLES <view> after LOCK 
> TABLES <view>.
> The reload_acl_and_cache() now looks into the VIEW definition
> to check the involved tables if the locked_tables_mode.

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

Chief Architect MariaDB
and secur...@mariadb.org

Mailing list: https://launchpad.net/~maria-developers
Post to     : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to