[MDEV-26086] FTRWL and FLUSH .. FOR EXPORT on TEMPTABLE view take too weak locks on underlying tables Created: 2021-07-03  Updated: 2021-07-03

Status: Open
Project: MariaDB Server
Component/s: Locking, Views
Affects Version/s: 10.6
Fix Version/s: 10.6

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-26087 InnoDB: Failing assertion: table->qui... Confirmed
relates to MDEV-15888 Implement FLUSH TABLES tbl_name [, tb... Closed

 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.



 Comments   
Comment by Elena Stepanova [ 2021-07-03 ]

Assigned to serg to define whether it's the expected behavior, as it is not obvious from the original task.

Generated at Thu Feb 08 09:42:38 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.