[MDEV-15888] Implement FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK for views Created: 2018-04-16  Updated: 2021-07-03  Resolved: 2021-05-31

Status: Closed
Project: MariaDB Server
Component/s: Views
Fix Version/s: 10.6.2

Type: Task Priority: Critical
Reporter: Geoff Montee (Inactive) Assignee: Alexey Botchkov
Resolution: Fixed Votes: 1
Labels: views

Issue Links:
Problem/Incident
causes MDEV-25837 Assertion `thd->locked_tables_mode ==... Closed
Relates
relates to MDEV-15890 Strange error message if you try to F... Closed
relates to MDEV-25906 SIGSEGV in flush_tables_with_read_loc... Closed
relates to MDEV-26086 FTRWL and FLUSH .. FOR EXPORT on TEMP... Open
relates to MDEV-26087 InnoDB: Failing assertion: table->qui... Confirmed

 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.

 Comments   
Comment by Sergei Golubchik [ 2018-04-17 ]

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.

Comment by Alexey Botchkov [ 2018-10-30 ]

http://lists.askmonty.org/pipermail/commits/2018-October/013042.html

Comment by Sergey Vojtovich [ 2019-01-11 ]

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.

Comment by Alexey Botchkov [ 2021-02-09 ]

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

Comment by Alexey Botchkov [ 2021-05-23 ]

https://github.com/MariaDB/server/commit/a40a36d9b9dc8b78171214905dce6d7fe19961d7

Comment by Sergei Golubchik [ 2021-05-26 ]

a40a36d9b9dc is ok to push

Comment by Alexey Botchkov [ 2021-05-31 ]

https://github.com/MariaDB/server/commit/b118f92be6b8d7294f3b57f824559ced3dcccc6b

Generated at Thu Feb 08 08:24:47 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.