Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
5.5(EOL), 10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL)
-
None
Description
Locked_tables_list::reopen_tables() is used under LOCK TABLES to reopen all tables that were closed. The failure to reopen might fail the whole statement.
This is wrong, because reopen might fail for reason completely unrelated to the current statement, because of something that happened earlier. Test case:
create table t1 (a int); |
create table t2 (b int); |
lock tables t1 write, t2 write, t1 t1_read read; |
-- drop table if exists t1;
|
repair table t2 use_frm; |
unlock tables;
|
drop table if exists t1; |
drop table if exists t2; |
this works. But if one uncomments drop table, repair will fail — because reopen_tables tries to reopen all closed tables, so it'll try to reopen t1, which no longer exists.
That's why in some cases the return value of Locked_tables_list::reopen_tables() is ignored (which doesn't help, as it still sets the error status in the thd), and sometimes it is followed by the thd->clear_error() (which is too indiscriminate, and still leaves a warning).
Ideally, Locked_tables_list::reopen_tables() will take a table as an argument and will reopen just that one table.
Attachments
Issue Links
- relates to
-
MDEV-15456 Server crashes upon adding or dropping a partition in ALTER under LOCK TABLE after ER_SAME_NAME_PARTITION
- Closed
-
MDEV-22292 Auto-repair doesn't work under LOCK TABLES
- Open