[MDEV-17983] CREATE TEMPORARY TABLE is inconsistent when refusing InnoDB table options Created: 2018-12-12  Updated: 2023-04-27

Status: Open
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2.2, 10.3.0, 10.4.0
Fix Version/s: 10.4

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Vladislav Lesin
Resolution: Unresolved Votes: 0
Labels: create_table, temporary

Issue Links:
Relates
relates to MDEV-17885 TRUNCATE on temporary table causes ER... Closed

 Description   

Starting with MariaDB Server 10.2.2, CREATE TEMPORARY TABLE in InnoDB actually creates temporary tables instead of persistent, redo-logged tables like it used to do. These tables are always created in a shared temporary tablespace.

However, CREATE TEMPORARY TABLE is not consistent when checking whether the table attributes are valid. The setting innodb_file_per_table should have no effect on the creation of temporary tables, but unfortunately it does have an effect:

--source include/have_innodb.inc
SET @save_per_table = @@GLOBAL.innodb_file_per_table;
SET GLOBAL innodb_file_per_table=1;
CREATE TEMPORARY TABLE t1 (a INT) ENGINE=InnoDB ENCRYPTED=NO;
DROP TEMPORARY TABLE t1;
SET GLOBAL innodb_file_per_table=0;
CREATE TEMPORARY TABLE t1 (a INT) ENGINE=InnoDB ENCRYPTED=NO;
SET GLOBAL innodb_file_per_table=@save_per_table;

The first CREATE TEMPORARY TABLE succeeds, but the second one will fail:

10.2 c913cd2b669f906f17c87b4c0864ae95b3911e03

mysqltest: At line 7: query 'CREATE TEMPORARY TABLE t1 (a INT) ENGINE=InnoDB ENCRYPTED=NO' failed: 1005: Can't create table `test`.`t1` (errno: 140 "Wrong create options")

serg suggested that we should issue errors if IGNORE_BAD_TABLE_OPTIONS sql_mode is not set, and warnings otherwise. To check for that option, it looks like thd_is_strict_mode() should be replaced with something that returns the sql_mode flags, or a new accessor function should be added.

When fixing this, please consider also the TRUNCATE code path, which was last fixed in MDEV-17885.


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