Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-17885

TRUNCATE on temporary table causes ER_GET_ERRNO and "Could not remove temporary table" in the log

Details

    Description

      It appears that innodb_safe_truncate makes TRUNCATE unsafe:

      --source include/have_innodb.inc
       
      CREATE TEMPORARY TABLE t1 (a INT) ENGINE=InnoDB;
      ALTER TABLE t1 ENCRYPTED=NO;
      TRUNCATE t1;
      

      10.2 861038f2e with default innodb_safe_truncate=ON

      CURRENT_TEST: bug.temp3
      mysqltest: At line 5: query 'TRUNCATE t1' failed: 1030: Got error 140 "Wrong create options" from storage engine InnoDB
      

      2018-12-01 13:41:46 140647973488384 [Warning] Could not remove temporary table: '/data/bld/10.2/mysql-test/var/tmp/mysqld.1/#sql769d_9_1', error: 2
      

      There is no warning/error with innodb_safe_truncate=OFF

      Attachments

        Issue Links

          Activity

            I think that TRUNCATE is correctly refusing and rolling back the operation, now that MDEV-17816 has been fixed.

            The actual error is that ALTER TABLE is lacking validation that is being done by CREATE TABLE. This is similar to MDEV-17833 (which was just fixed) and should be fixed in 10.1 (which was the first version to introduce table options in InnoDB/XtraDB).

            marko Marko Mäkelä added a comment - I think that TRUNCATE is correctly refusing and rolling back the operation, now that MDEV-17816 has been fixed. The actual error is that ALTER TABLE is lacking validation that is being done by CREATE TABLE . This is similar to MDEV-17833 (which was just fixed) and should be fixed in 10.1 (which was the first version to introduce table options in InnoDB/XtraDB).

            Actually, CREATE appears to accept the table options, but TRUNCATE will complain:

            --source include/have_innodb.inc
            CREATE TEMPORARY TABLE t1 (a INT) ENGINE=InnoDB ENCRYPTED=NO;
            TRUNCATE TABLE t1;
            

            marko Marko Mäkelä added a comment - Actually, CREATE appears to accept the table options, but TRUNCATE will complain: --source include/have_innodb.inc CREATE TEMPORARY TABLE t1 (a INT ) ENGINE=InnoDB ENCRYPTED= NO ; TRUNCATE TABLE t1;

            With the following fix, CREATE TEMPORARY TABLE would reject those table options that are only valid for .ibd files:

            diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc
            index 717b67290dc..567be3378a1 100644
            --- a/storage/innobase/handler/ha_innodb.cc
            +++ b/storage/innobase/handler/ha_innodb.cc
            @@ -12911,7 +12911,9 @@ ha_innobase::create(
             	TABLE*		form,
             	HA_CREATE_INFO*	create_info)
             {
            -	return create(name, form, create_info, srv_file_per_table);
            +	return create(name, form, create_info,
            +		      !(create_info->options & HA_LEX_CREATE_TMP_TABLE)
            +		      && srv_file_per_table);
             }
             
             /*****************************************************************//**
            

            However, this would introduce a regression for CREATE TEMPORARY TABLE behaviour in the generally available 10.2 and 10.3 series. The following would allow the TRUNCATE TABLE to succeed:

            diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc
            index 717b67290dc..b941ce8b825 100644
            --- a/storage/innobase/handler/ha_innodb.cc
            +++ b/storage/innobase/handler/ha_innodb.cc
            @@ -13531,7 +13531,8 @@ int ha_innobase::truncate()
             		row_mysql_unlock_data_dictionary(trx);
             	} else {
             		err = create(name, table, &info,
            -			     dict_table_is_file_per_table(ib_table), trx);
            +			     ib_table->is_temporary()
            +			     || dict_table_is_file_per_table(ib_table), trx);
             	}
             
             	trx_free_for_mysql(trx);
            

            marko Marko Mäkelä added a comment - With the following fix, CREATE TEMPORARY TABLE would reject those table options that are only valid for .ibd files: diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc index 717b67290dc..567be3378a1 100644 --- a/storage/innobase/handler/ha_innodb.cc +++ b/storage/innobase/handler/ha_innodb.cc @@ -12911,7 +12911,9 @@ ha_innobase::create( TABLE* form, HA_CREATE_INFO* create_info) { - return create(name, form, create_info, srv_file_per_table); + return create(name, form, create_info, + !(create_info->options & HA_LEX_CREATE_TMP_TABLE) + && srv_file_per_table); } /*****************************************************************//** However, this would introduce a regression for CREATE TEMPORARY TABLE behaviour in the generally available 10.2 and 10.3 series. The following would allow the TRUNCATE TABLE to succeed: diff --git a/storage/innobase/handler/ha_innodb.cc b/storage/innobase/handler/ha_innodb.cc index 717b67290dc..b941ce8b825 100644 --- a/storage/innobase/handler/ha_innodb.cc +++ b/storage/innobase/handler/ha_innodb.cc @@ -13531,7 +13531,8 @@ int ha_innobase::truncate() row_mysql_unlock_data_dictionary(trx); } else { err = create(name, table, &info, - dict_table_is_file_per_table(ib_table), trx); + ib_table->is_temporary() + || dict_table_is_file_per_table(ib_table), trx); } trx_free_for_mysql(trx);

            I filed MDEV-17983 for making CREATE TEMPORARY TABLE stricter.

            marko Marko Mäkelä added a comment - I filed MDEV-17983 for making CREATE TEMPORARY TABLE stricter.

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.