Debugging this:

create table t1 (a int, b int, c int) engine=rocksdb;

insert into t1 select seq, seq, seq from seq_1_to_100000;

set rocksdb_tmpdir='/tmp/bbb'

alter table t1 add key(c);

The execution reaches this point in storage/rocksdb/rdb_index_merge.cc:

/**

  Create a merge file in the given location.

*/

int Rdb_index_merge::merge_file_create() {

  DBUG_ASSERT(m_merge_file.m_fd == -1);

  int fd;

#ifdef MARIAROCKS_NOT_YET // mysql_tmpfile_path use 

  /* If no path set for tmpfile, use mysql_tmpdir by default */

  if (m_tmpfile_path == nullptr) {

    fd = mysql_tmpfile("myrocks");

  } else {

    fd = mysql_tmpfile_path(m_tmpfile_path, "myrocks");

  }

#else

  fd = mysql_tmpfile("myrocks");

#endif

Indeed, it is not using m_tmpfile_path...

The upstream uses mysql_tmpfile_path, which is not present in MariaDB.

mysql_tmpfile_path was introduced by:

commit 747682305b12d5f9521af090c105225a995740e4

Author:	Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>  Thu Nov 19 12:49:23 2015

Committer:	Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>  Thu Nov 19 12:49:23 2015

Bug #19183565 CREATE DYNAMIC INNODB_TMPDIR VARIABLE TO CONTROL

		WHERE INNODB WRITES TEMP FILES

Problem:

========

InnoDB creates temporary files for online ALTER statements in the tmpdir.

In some cases, the tmpdir is too small, or for other reasons, not the best

choice.

Solution:

=========

Create a new dynamic session variable "innodb_tmpdir"

that would determine where the temp files should create during alter

operation.

It's interesting that InnoDB in MariaDB seems to have innodb_tmpdir.

InnoDB's handing of temp files does quite a few checks buy eventually calls create_temp_file():

File create_temp_file(char *to, const char *dir, const char *prefix,

		      int mode, myf MyFlags)

It seems like it's possible to use create_temp_file . I'd need to have a discussion about this before jumping to implement it.

http://lists.askmonty.org/pipermail/commits/2022-January/014865.html

serg, could you please review?

bb-10.2-mdev25447

Why every engine wants to use it's own tmpdir? And even as a session variable. At least, InnoDB checks that the user has FILE privilege, RocksDB doesn't do even that.

I think there should be only one tmpdir, in the server. We can make it modifiable, though, as that seems to be the reason for the proliferation of per-engine tmpdirs.

serg

Why every engine wants to use it's own tmpdir? And even as a session variable.

Is this a rhetorical question or acknowledgment of ones' ignorance?

I assume there must be some solid reason as different people seem to have specifically bothered about this: both MyRocks developers (see https://github.com/facebook/mysql-5.6/issues/455) and the customer that has filed the associated support ticket.

At least, InnoDB checks that the user has FILE privilege, RocksDB doesn't do even that.

I agree that a request to perform permission checks is reasonable. The checking function should probably be at the SQL layer.

I think there should be only one tmpdir, in the server. We can make it modifiable, though, as that seems to be the reason for the proliferation of per-engine tmpdirs.

Besides tmpdirs, the engines allow one to specify where the data files are placed: see innodb_data_home_dir, rocksdb_datadir, rocksdb_waldir.

I assume that performance dictates that engine's tmpdir is located on the same volume as its datadir.

Are we going to reject the engine's right to use its own directories?

Acknowledgement. I really don't know why and want to understand it. My guess is (see above) that it's because @@tmpdir is read-only and engine developers wanted to be able to modify it. The original bug description seems to imply the same.

I assume that performance dictates that engine's tmpdir is located on the same volume as its datadir.

1. if one wants to create a new "temporary" table file and then rename it to the non-temporary table name — then yes, but those files are not created in the tmpdir.
2. otherwise for performance it's better to have them on a separate volume

Are we going to reject the engine's right to use its own directories?

No, we have no way of doing it. The engine can do anything it wants, even when it's wrong or bad for the user experience. But we don't have to encourage that. So the question is — is there a good reason for engines to have their own tmpdirs? If yes — we should help them to do it. If not — we should help them not to.

pramod.mahto@mariadb.com, why would anyone want to change rocksdb_tmpdir? What is the point of it, what benefits does it have?

Note to self: study what tmp files myrocks are created for:
1. for injection into the data directory
2. for just temporary files.

and then the engine should create the files eitehr at the datadir (for #1) or at the temp.dir (for #2).

Also, for temporary files, one might want to change tmpdir for one specific query (to handle very big queries). This can be fixed by making tmpdir writable (currently, tmpdir is not writable, innodb_tmpdir is writable (with some security checks made), rocksdb_tmpdir is writable (without any checks)).

moved the feature to MDEV-28485