Hi Serg!
Thanks for the review.
On Fri, Apr 20, 2018 at 6:36 PM, Sergei Golubchik
Hi, Sachin!
On Apr 19, sachin wrote:
diff --git a/storage/perfschema/ha_perfschema.cc b/storage/perfschema/ha_perfschema.cc index e8e9581..d5846f2 100644 --- a/storage/perfschema/ha_perfschema.cc +++ b/storage/perfschema/ha_perfschema.cc @@ -64,6 +64,16 @@ static int pfs_discover_table(handlerton *hton, THD *thd, TABLE_SHARE *share) { const PFS_engine_table_share *pfs_share;
+ DBUG_EXECUTE_IF("test_pseudo_invisible", { + my_error(ER_INTERNAL_ERROR, MYF(0), "Don't query performance_schema when" + "test_pseudo_invisible is on"); + return 1; + }); + DBUG_EXECUTE_IF("test_completely_invisible", { + my_error(ER_INTERNAL_ERROR, MYF(0), "Don't query performance_schema when" + "test_completely_invisible is on"); + return 1; + }); if ((pfs_share= find_table_share(share->db.str, share->table_name.str))) return share->init_from_sql_statement_string(thd, false, pfs_share->sql.str,
Better put it inside TABLE_SHARE::init_from_sql_statement_string to cover Connect and FederatedX too.
Or - I'd say it's an option too - just close it as not a bug. DBUG_EXECUTE_IF can cause a crash, can make a server to misbehave, etc. That's normal, it's a debug hack that intentionally makes server to do something weird. I wouldn't spend too much time on making it user friendly and error-proof. Actually I agree with second option, dbug_debug can really be dangerous and are used for internal purpose only. So I am closing this as not a bug.
Regards, Sergei Chief Architect MariaDB and security@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