Merge lp:~gl-az/percona-server/BT-23310-bug1218664-5.5 into lp:percona-server/5.5

[George Ormond Lorch III]

Fix for https://bugs.launchpad.net/percona-server/+bug/1218664 - Ignore "enforce_storage_engine" option on "mysql" and "performance_schema" databases.

Fixed by disabling enforcement during any bootstrap or skip-grants-tables server start.

Discovered https://bugs.launchpad.net/percona-server/+bug/1233354 and fixed by calling plugin_unlock in plugin name and default checking in mysqld.cc where enforce_storage_engine name is being validated

http://jenkins.percona.com/view/PS%205.5/job/percona-server-5.5-param/883/

[Laurynas Biveinis (laurynas-biveinis)]

    - It is suspicious that we want to include PERCONA_SCHEMA. Why?
      Shouldn't it be treated as user table for our purposes?
      Also wouldn't it provide a hole around schema enforcement if
      the server is missing PERCONA_SCHEMA schema, thus user is free
      to create it? Such scenario is exactly how the MTR testcase
      currently works, isn't it?

    - Assuming PERCONA_SCHEMA is not desired, then there is no need
      to maintain our own list of special schemas (also what about
      case sensitivity?) There is get_table_category(), which will
      return TABLE_CATEGORY_INFORMATION for I_S,
      TABLE_CATEGORY_PERFROMANCE for P_S, TABLE_CATEGORY_SYSTEM for
      mysql, TABLE_CATEGORY_LOG for slow/general logs if tables, and
      TABLE_CATEGORY_USER. Thus it seems that we can simply call
      get_table_category() and enforce storage engine only if it
      returned TABLE_CATEGORY_USER. Note that it would cover log
      tables as well, which we haven't discussed previously, but for
      which SE enforcement is probably a bug too.

    - Assuming PERCONA_SCHEMA is not desired, an MTR testcase becomes
      more complicated. I'd look if it is possible to test through
      the log tables, if possible.

review: Needs Fixing

[George Ormond Lorch III (gl-az)]

On 9/26/2013 11:18 PM, Laurynas Biveinis wrote:
> Review: Needs Fixing
>
> - It is suspicious that we want to include PERCONA_SCHEMA. Why?
> Shouldn't it be treated as user table for our purposes?
> Also wouldn't it provide a hole around schema enforcement if
> the server is missing PERCONA_SCHEMA schema, thus user is free
> to create it? Such scenario is exactly how the MTR testcase
> currently works, isn't it?
>
> - Assuming PERCONA_SCHEMA is not desired, then there is no need
> to maintain our own list of special schemas (also what about
> case sensitivity?) There is get_table_category(), which will
> return TABLE_CATEGORY_INFORMATION for I_S,
> TABLE_CATEGORY_PERFROMANCE for P_S, TABLE_CATEGORY_SYSTEM for
> mysql, TABLE_CATEGORY_LOG for slow/general logs if tables, and
> TABLE_CATEGORY_USER. Thus it seems that we can simply call
> get_table_category() and enforce storage engine only if it
> returned TABLE_CATEGORY_USER. Note that it would cover log
> tables as well, which we haven't discussed previously, but for
> which SE enforcement is probably a bug too.
>
> - Assuming PERCONA_SCHEMA is not desired, an MTR testcase becomes
> more complicated. I'd look if it is possible to test through
> the log tables, if possible.
>
I was entirely unaware of this get_table_category(). This is IMHO the
correct way to do it and I even almost implemented such a call like
'get_schema_type' or something along those lines. I do think though that
PERCONA_SCHEMA does need some protection but it is hard to say right now
because it is so new and nobody yet seems to have any idea or opinion on
it. I suppose we could always add it in later but by then it may be too
late (closing the door after the horse is out of the barn). This is a
sticky integration point between XB and PS. By not protecting it then
yes, it does make creating a proper test case more difficult but as you
say, we could try with the log tables...

[George Ormond Lorch III (gl-az)]

TABLE_CATEGORY_USER seems to refer to the mysql users table, not an end
user table.

On 9/27/2013 12:06 AM, George Ormond Lorch III wrote:
> On 9/26/2013 11:18 PM, Laurynas Biveinis wrote:
>> Review: Needs Fixing
>>
>> - It is suspicious that we want to include PERCONA_SCHEMA. Why?
>> Shouldn't it be treated as user table for our purposes?
>> Also wouldn't it provide a hole around schema enforcement if
>> the server is missing PERCONA_SCHEMA schema, thus user is free
>> to create it? Such scenario is exactly how the MTR testcase
>> currently works, isn't it?
>>
>> - Assuming PERCONA_SCHEMA is not desired, then there is no need
>> to maintain our own list of special schemas (also what about
>> case sensitivity?) There is get_table_category(), which will
>> return TABLE_CATEGORY_INFORMATION for I_S,
>> TABLE_CATEGORY_PERFROMANCE for P_S, TABLE_CATEGORY_SYSTEM for
>> mysql, TABLE_CATEGORY_LOG for slow/general logs if tables, and
>> TABLE_CATEGORY_USER. Thus it seems that we can simply call
>> get_table_category() and enforce storage engine only if it
>> returned TABLE_CATEGORY_USER. Note that it would cover log
>> tables as well, which we haven't discussed previously, but for
>> which SE enforcement is probably a bug too.
>>
>> - Assuming PERCONA_SCHEMA is not desired, an MTR testcase becomes
>> more complicated. I'd look if it is possible to test through
>> the log tables, if possible.
>>
> I was entirely unaware of this get_table_category(). This is IMHO the
> correct way to do it and I even almost implemented such a call like
> 'get_schema_type' or something along those lines. I do think though that
> PERCONA_SCHEMA does need some protection but it is hard to say right now
> because it is so new and nobody yet seems to have any idea or opinion on
> it. I suppose we could always add it in later but by then it may be too
> late (closing the door after the horse is out of the barn). This is a
> sticky integration point between XB and PS. By not protecting it then
> yes, it does make creating a proper test case more difficult but as you
> say, we could try with the log tables...
>

[George Ormond Lorch III (gl-az)]

OK, so on further testing of an in place upgrade of 5.5 to 5.6, it seems that there are system tables that are reporting as TABLE_CATEGORY_USER, specifically, the mysql.user table. Creating a regular end-user table is also of this type. So on running mysql_upgrade with some printing of interesting info from within check_engine() I get lots of errors (many trimmed for brevity):
**** check_engine db_name[mysql] table_name[user] category[2] no_substitution[0] enf_engine[1]
InnoDB: Error: trying to create a MySQL system table mysql/user of type InnoDB.
InnoDB: MySQL system tables must be of the MyISAM type!
**** check_engine db_name[mysql] table_name[db] category[2] no_substitution[0] enf_engine[1]
InnoDB: Error: trying to create a MySQL system table mysql/db of type InnoDB.
InnoDB: MySQL system tables must be of the MyISAM type!

Then eventually a server crash:
mysqld-debug: /home/glorch/dev/bug1218664/5.6/Percona-Server/sql/sql_error.cc:430: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `! is_set()' failed.
18:14:09 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Please help us make Percona Server better by reporting any
bugs at http://bugs.percona.com/

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=1
max_threads=153
thread_count=1
connection_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 69137 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x3c6e4b0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f0e74456de0 thread_stack 0x40000
/data/bin/bug1218664/5.6/bin/mysqld-debug(my_print_stacktrace+0x35)[0xabc4ec]
/data/bin/bug1218664/5.6/bin/mysqld-debug(handle_fatal_signal+0x42e)[0x7316b6]
/lib64/libpthread.so.0[0x391b00f500]
/lib64/libc.so.6(gsignal+0x35)[0x391a8328a5]
/lib64/libc.so.6(abort+0x175)[0x391a834085]
/lib64/libc.so.6[0x391a82ba1e]
/lib64/libc.so.6(__assert_perror_fail+0x0)[0x391a82bae0]
/data/bin/bug1218664/5.6/bin/mysqld-debug(_ZN16Diagnostics_area13set_ok_statusEyyPKc+0x66)[0x7afcde]
/data/bin/bug1218664/5.6/bin/mysqld-debug(_Z5my_okP3THDyyPKc+0x4f)[0x7692c0]
/data/bin/bug1218664/5.6/bin/mysqld-debug(_Z17mysql_alter_tableP3THDPcS1_P24st_ha_create_informationP10TABLE_LISTP10Alter_infojP8st_orderb+0x2606)[0x85ea4f]
/data/bin/bug1218664/5.6/bin/mysqld-debug(_ZN19Sql_cmd_alter_table7executeEP3THD+0x51e)[0x9a95e4]
/data/bin/bug1218664/5.6/bin/mysqld-debug(_Z21mysql_execute_commandP3THD+0x7e26)[0x7eba9e]
/data/bin/bug1218664/5.6/bin/mysqld-debug(_Z11mysql_parseP3THDPcjP12Parser_state+0x58a)[0x7eed42]
/data/bin/bug1218664/5.6/bi...

[Laurynas Biveinis (laurynas-biveinis)]

Oh, right. In that case we'd need combined solution: if get_table_category() == USER, then compare its db name against MYSQL_SCHEMA_NAME.

> TABLE_CATEGORY_USER seems to refer to the mysql users table, not an end
> user table.
>
> On 9/27/2013 12:06 AM, George Ormond Lorch III wrote:
> > On 9/26/2013 11:18 PM, Laurynas Biveinis wrote:
> >> Review: Needs Fixing
> >>
> >> - It is suspicious that we want to include PERCONA_SCHEMA. Why?
> >> Shouldn't it be treated as user table for our purposes?
> >> Also wouldn't it provide a hole around schema enforcement if
> >> the server is missing PERCONA_SCHEMA schema, thus user is free
> >> to create it? Such scenario is exactly how the MTR testcase
> >> currently works, isn't it?
> >>
> >> - Assuming PERCONA_SCHEMA is not desired, then there is no need
> >> to maintain our own list of special schemas (also what about
> >> case sensitivity?) There is get_table_category(), which will
> >> return TABLE_CATEGORY_INFORMATION for I_S,
> >> TABLE_CATEGORY_PERFROMANCE for P_S, TABLE_CATEGORY_SYSTEM for
> >> mysql, TABLE_CATEGORY_LOG for slow/general logs if tables, and
> >> TABLE_CATEGORY_USER. Thus it seems that we can simply call
> >> get_table_category() and enforce storage engine only if it
> >> returned TABLE_CATEGORY_USER. Note that it would cover log
> >> tables as well, which we haven't discussed previously, but for
> >> which SE enforcement is probably a bug too.
> >>
> >> - Assuming PERCONA_SCHEMA is not desired, an MTR testcase becomes
> >> more complicated. I'd look if it is possible to test through
> >> the log tables, if possible.
> >>
> > I was entirely unaware of this get_table_category(). This is IMHO the
> > correct way to do it and I even almost implemented such a call like
> > 'get_schema_type' or something along those lines. I do think though that
> > PERCONA_SCHEMA does need some protection but it is hard to say right now
> > because it is so new and nobody yet seems to have any idea or opinion on
> > it. I suppose we could always add it in later but by then it may be too
> > late (closing the door after the horse is out of the barn). This is a
> > sticky integration point between XB and PS. By not protecting it then
> > yes, it does make creating a proper test case more difficult but as you
> > say, we could try with the log tables...
> >

[George Ormond Lorch III (gl-az)]

I was also thinking that maybe --skip-grants-tables could/should disable
the enforcement...

On 9/30/2013 7:48 AM, Laurynas Biveinis wrote:
> Oh, right. In that case we'd need combined solution: if get_table_category() == USER, then compare its db name against MYSQL_SCHEMA_NAME.
>
>> TABLE_CATEGORY_USER seems to refer to the mysql users table, not an end
>> user table.
>>
>> On 9/27/2013 12:06 AM, George Ormond Lorch III wrote:
>>> On 9/26/2013 11:18 PM, Laurynas Biveinis wrote:
>>>> Review: Needs Fixing
>>>>
>>>> - It is suspicious that we want to include PERCONA_SCHEMA. Why?
>>>> Shouldn't it be treated as user table for our purposes?
>>>> Also wouldn't it provide a hole around schema enforcement if
>>>> the server is missing PERCONA_SCHEMA schema, thus user is free
>>>> to create it? Such scenario is exactly how the MTR testcase
>>>> currently works, isn't it?
>>>>
>>>> - Assuming PERCONA_SCHEMA is not desired, then there is no need
>>>> to maintain our own list of special schemas (also what about
>>>> case sensitivity?) There is get_table_category(), which will
>>>> return TABLE_CATEGORY_INFORMATION for I_S,
>>>> TABLE_CATEGORY_PERFROMANCE for P_S, TABLE_CATEGORY_SYSTEM for
>>>> mysql, TABLE_CATEGORY_LOG for slow/general logs if tables, and
>>>> TABLE_CATEGORY_USER. Thus it seems that we can simply call
>>>> get_table_category() and enforce storage engine only if it
>>>> returned TABLE_CATEGORY_USER. Note that it would cover log
>>>> tables as well, which we haven't discussed previously, but for
>>>> which SE enforcement is probably a bug too.
>>>>
>>>> - Assuming PERCONA_SCHEMA is not desired, an MTR testcase becomes
>>>> more complicated. I'd look if it is possible to test through
>>>> the log tables, if possible.
>>>>
>>> I was entirely unaware of this get_table_category(). This is IMHO the
>>> correct way to do it and I even almost implemented such a call like
>>> 'get_schema_type' or something along those lines. I do think though that
>>> PERCONA_SCHEMA does need some protection but it is hard to say right now
>>> because it is so new and nobody yet seems to have any idea or opinion on
>>> it. I suppose we could always add it in later but by then it may be too
>>> late (closing the door after the horse is out of the barn). This is a
>>> sticky integration point between XB and PS. By not protecting it then
>>> yes, it does make creating a proper test case more difficult but as you
>>> say, we could try with the log tables...
>>>

--
George O. Lorch III
Software Engineer, Percona
[phone] x542 US/Arizona (GMT -7)
skype: george.ormond.lorch.iii

[Laurynas Biveinis (laurynas-biveinis)]

Is the upgrade issue resolved if we skip enforcing SE for everything in mysql, including TABLE_CATEGORY_USER tables, as in another reply?

> OK, so on further testing of an in place upgrade of 5.5 to 5.6, it seems that
> there are system tables that are reporting as TABLE_CATEGORY_USER,
> specifically, the mysql.user table. Creating a regular end-user table is also
> of this type. So on running mysql_upgrade with some printing of interesting
> info from within check_engine() I get lots of errors (many trimmed for
> brevity):
> **** check_engine db_name[mysql] table_name[user] category[2]
> no_substitution[0] enf_engine[1]
> InnoDB: Error: trying to create a MySQL system table mysql/user of type
> InnoDB.
> InnoDB: MySQL system tables must be of the MyISAM type!
> **** check_engine db_name[mysql] table_name[db] category[2]
> no_substitution[0] enf_engine[1]
> InnoDB: Error: trying to create a MySQL system table mysql/db of type InnoDB.
> InnoDB: MySQL system tables must be of the MyISAM type!
>
> Then eventually a server crash:
> mysqld-debug: /home/glorch/dev/bug1218664/5.6/Percona-
> Server/sql/sql_error.cc:430: void Diagnostics_area::set_ok_status(ulonglong,
> ulonglong, const char*): Assertion `! is_set()' failed.
> 18:14:09 UTC - mysqld got signal 6 ;
> This could be because you hit a bug. It is also possible that this binary
> or one of the libraries it was linked against is corrupt, improperly built,
> or misconfigured. This error can also be caused by malfunctioning hardware.
> We will try our best to scrape up some info that will hopefully help
> diagnose the problem, but since we have already crashed,
> something is definitely wrong and this may fail.
> Please help us make Percona Server better by reporting any
> bugs at http://bugs.percona.com/
>
> key_buffer_size=8388608
> read_buffer_size=131072
> max_used_connections=1
> max_threads=153
> thread_count=1
> connection_count=1
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 69137 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x3c6e4b0
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> stack_bottom = 7f0e74456de0 thread_stack 0x40000
> /data/bin/bug1218664/5.6/bin/mysqld-debug(my_print_stacktrace+0x35)[0xabc4ec]
> /data/bin/bug1218664/5.6/bin/mysqld-debug(handle_fatal_signal+0x42e)[0x7316b6]
> /lib64/libpthread.so.0[0x391b00f500]
> /lib64/libc.so.6(gsignal+0x35)[0x391a8328a5]
> /lib64/libc.so.6(abort+0x175)[0x391a834085]
> /lib64/libc.so.6[0x391a82ba1e]
> /lib64/libc.so.6(__assert_perror_fail+0x0)[0x391a82bae0]
> /data/bin/bug1218664/5.6/bin/mysqld-
> debug(_ZN16Diagnostics_area13set_ok_statusEyyPKc+0x66)[0x7afcde]
> /data/bin/bug1218664/5.6/bin/mysqld-debug(_Z5my_okP3THDyyPKc+0x4f)[0x7692c0]
> /data/bin/bug1218664/5.6/bin/mysqld-debug(_Z17mysql_alter_tableP3THDPcS1_P24st
> _ha_create_informationP10TABLE_LISTP10Alter_infojP8st_orderb+0x2606)[0x85ea4f]
> /data/bin/bug1218664/5.6/bin/mysqld-
> debug(_ZN19Sql_cmd_alter...

[George Ormond Lorch III (gl-az)]

Probably, whic brings us back to the original fix and problem if (is in
schema mysql) {don't enforce} which then allows any user to bypass
enforcement by simply creating a table within mysql schema is their
privs haven't been restricted.

On 9/30/2013 7:49 AM, Laurynas Biveinis wrote:
> Is the upgrade issue resolved if we skip enforcing SE for everything in mysql, including TABLE_CATEGORY_USER tables, as in another reply?
>
>> OK, so on further testing of an in place upgrade of 5.5 to 5.6, it seems that
>> there are system tables that are reporting as TABLE_CATEGORY_USER,
>> specifically, the mysql.user table. Creating a regular end-user table is also
>> of this type. So on running mysql_upgrade with some printing of interesting
>> info from within check_engine() I get lots of errors (many trimmed for
>> brevity):
>> **** check_engine db_name[mysql] table_name[user] category[2]
>> no_substitution[0] enf_engine[1]
>> InnoDB: Error: trying to create a MySQL system table mysql/user of type
>> InnoDB.
>> InnoDB: MySQL system tables must be of the MyISAM type!
>> **** check_engine db_name[mysql] table_name[db] category[2]
>> no_substitution[0] enf_engine[1]
>> InnoDB: Error: trying to create a MySQL system table mysql/db of type InnoDB.
>> InnoDB: MySQL system tables must be of the MyISAM type!
>>
>> Then eventually a server crash:
>> mysqld-debug: /home/glorch/dev/bug1218664/5.6/Percona-
>> Server/sql/sql_error.cc:430: void Diagnostics_area::set_ok_status(ulonglong,
>> ulonglong, const char*): Assertion `! is_set()' failed.
>> 18:14:09 UTC - mysqld got signal 6 ;
>> This could be because you hit a bug. It is also possible that this binary
>> or one of the libraries it was linked against is corrupt, improperly built,
>> or misconfigured. This error can also be caused by malfunctioning hardware.
>> We will try our best to scrape up some info that will hopefully help
>> diagnose the problem, but since we have already crashed,
>> something is definitely wrong and this may fail.
>> Please help us make Percona Server better by reporting any
>> bugs at http://bugs.percona.com/
>>
>> key_buffer_size=8388608
>> read_buffer_size=131072
>> max_used_connections=1
>> max_threads=153
>> thread_count=1
>> connection_count=1
>> It is possible that mysqld could use up to
>> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 69137 K
>> bytes of memory
>> Hope that's ok; if not, decrease some variables in the equation.
>>
>> Thread pointer: 0x3c6e4b0
>> Attempting backtrace. You can use the following information to find out
>> where mysqld died. If you see no messages after this, something went
>> terribly wrong...
>> stack_bottom = 7f0e74456de0 thread_stack 0x40000
>> /data/bin/bug1218664/5.6/bin/mysqld-debug(my_print_stacktrace+0x35)[0xabc4ec]
>> /data/bin/bug1218664/5.6/bin/mysqld-debug(handle_fatal_signal+0x42e)[0x7316b6]
>> /lib64/libpthread.so.0[0x391b00f500]
>> /lib64/libc.so.6(gsignal+0x35)[0x391a8328a5]
>> /lib64/libc.so.6(abort+0x175)[0x391a834085]
>> /lib64/libc.so.6[0x391a82ba1e]
>> /lib64/libc.so.6(__assert_perror_fail+0x0)[0x391a82bae0]
>> /data/bin/bug1218664/5.6/bin/mysqld-
>> debug(_ZN16Diagnostics_area...

[Laurynas Biveinis (laurynas-biveinis)]

George -

I am not sure re. the use case of this feature. Surely creation of tables in mysql by users can be prevented by a proper GRANT setup? If for some reason no, then there is also mysqld_system_tables[] list in handler.cc.

[George Ormond Lorch III (gl-az)]

Fixed as discussed on IRC, fixed newly discovered bug, jenkins:
http://jenkins.percona.com/view/PS%205.5/job/percona-server-5.5-param/883/

[George Ormond Lorch III (gl-az)]

Ohh yeah, forgot to mention. Complete cycle from mysql_install_db through mysql_upgrade (with --skip-grant-tables) tested locally under valgrind with enforce-storage-engine=innodb in all my.cnf works perfectly now.

[Laurynas Biveinis (laurynas-biveinis)]

George -

The code looks good, but now the linked bugs must be adjusted to match:
1) 1233354 is OK;
2) it is not 1218664 which is being fixed there. Rather, it's another bug/feature request to skip enforcement whenever we are in bootstrap or skipped grants tables mode, and should be logged as such?
3) and 1218664 should be converted to doc bug.

review: Needs Fixing

=== modified file 'Percona-Server/sql/mysqld.cc'
--- Percona-Server/sql/mysqld.cc	2013-09-09 06:59:26 +0000
+++ Percona-Server/sql/mysqld.cc	2013-10-08 16:09:55 +0000
@@ -4081,7 +4081,7 @@
   /*
     Validate any enforced storage engine
   */
-  if (enforce_storage_engine)
+  if (enforce_storage_engine && !opt_bootstrap && !opt_noacl)
   {
     LEX_STRING name= { enforce_storage_engine,
       strlen(enforce_storage_engine) };
@@ -4104,6 +4104,8 @@
             enforce_storage_engine);
         }
       }
+      plugin_unlock(0, defplugin);
+      plugin_unlock(0, plugin);
     }
     else
     {

=== modified file 'Percona-Server/sql/sql_table.cc'
--- Percona-Server/sql/sql_table.cc	2013-08-02 09:40:55 +0000
+++ Percona-Server/sql/sql_table.cc	2013-10-08 16:09:55 +0000
@@ -52,6 +52,7 @@
 #include "sql_show.h"
 #include "transaction.h"
 #include "datadict.h"  // dd_frm_type()
+#include "mysql.h"			// in_bootstrap & opt_noacl
 
 #ifdef __WIN__
 #include <io.h>
@@ -7660,11 +7661,14 @@
   DBUG_ENTER("check_engine");
   handlerton **new_engine= &create_info->db_type;
   handlerton *req_engine= *new_engine;
-  handlerton *enf_engine= ha_enforce_handlerton(thd);
+  handlerton *enf_engine= NULL;
 
   bool no_substitution=
         test(thd->variables.sql_mode & MODE_NO_ENGINE_SUBSTITUTION);
 
+  if (!in_bootstrap && !opt_noacl)
+    enf_engine= ha_enforce_handlerton(thd);
+
   if (!(*new_engine= ha_checktype(thd, ha_legacy_type(req_engine),
                                   no_substitution, 1)))
     DBUG_RETURN(true);