You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
plan replayer can't handle views correctly if it's dumped and loaded by different users #59653
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
mysql -h 127.0.0.1 -P 4000 -u root
createuser 'test1';
grant all privileges on test.* to 'test1';
mysql -h 127.0.0.1 -P 4000 -u test1
use test;
createtablet(a int, b int);
createviewv1asselect a from t;
plan replayer dump explain select*from v1;
Start a new tidb cluster.
mysql -h 127.0.0.1 -P 4000 -u root
plan replayer load 'xxx';
explain select*from v1;
2. What did you expect to see? (Required)
The execution plan is displayed.
3. What did you see instead (Required)
> explain select * from v1;
ERROR 1356 (HY000): View 'test.v1' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
changed the title [-]plan replayer can't handle views well it's dumped and loaded by different users[/-][+]plan replayer can't handle views correctly if it's dumped and loaded by different users[/+]on Feb 19, 2025
If you look at the definition of the view in the plan replayer, you'll find:
createdatabaseif not exists `test`; use `test`;
CREATE ALGORITHM=UNDEFINED DEFINER=`test1`@`%` SQL SECURITY DEFINER VIEW `v1` (`a`) ASSELECT`a`AS`a`FROM`test`.`t`
Notice the DEFINER=`test1`@`%` SQL SECURITY DEFINER here.
By default, if it's not specified in the create view statement, the DEFINER would be the current user, and the SQL SECURITY would be DEFINER. This means no matter who is querying this view, it's using the privilege of the DEFINER.
When we load the plan replayer, usually we'll use the root user. Apparently the DEFINER, i.e. the test1 user, doesn't have the privilege to query the test.t table in the new environment.
Workaround
If you meet the error when loading the plan replayer, you can drop the views, remove the DEFINER clause from the create view statements, and manually create the views again.
Possible fix
Do not include the DEFINER and SQL SECURITY clauses for view definitions when dumpling the plan replayer.
Forcefully specify SQL SECURITY INVOKER for view definitions when dumpling the plan replayer.
I vote for #1 since most likely replayer is not used to debug issues related to privileges. Also, I suggest adding description of this behaviour to the docs.
Activity
[-]plan replayer can't handle views well it's dumped and loaded by different users[/-][+]plan replayer can't handle views correctly if it's dumped and loaded by different users[/+]time-and-fate commentedon Feb 19, 2025
Root cause
If you look at the definition of the view in the plan replayer, you'll find:
Notice the
DEFINER=`test1`@`%` SQL SECURITY DEFINERhere.By default, if it's not specified in the
create viewstatement, theDEFINERwould be the current user, and theSQL SECURITYwould beDEFINER. This means no matter who is querying this view, it's using the privilege of theDEFINER.When we load the plan replayer, usually we'll use the
rootuser. Apparently theDEFINER, i.e. thetest1user, doesn't have the privilege to query thetest.ttable in the new environment.Workaround
If you meet the error when loading the plan replayer, you can drop the views, remove the
DEFINERclause from thecreate viewstatements, and manually create the views again.Possible fix
DEFINERandSQL SECURITYclauses for view definitions when dumpling the plan replayer.SQL SECURITY INVOKERfor view definitions when dumpling the plan replayer.ghazalfamilyusa commentedon Feb 20, 2025
I vote for #1 since most likely replayer is not used to debug issues related to privileges. Also, I suggest adding description of this behaviour to the docs.