If I use BIGINT in table definition

CREATE TABLE t1 (a BIGINT) ENGINE=RocksDB PARTITION BY HASH(a) PARTITIONS 2;

I get a bigger leak.

Analysis:

Ok ,the cause seems to be in ha_partition::change_partitions().
It calls get_new_handler to create ha_rocksdb objects for the new partitions but then these objects are never deleted properly.
The objects are put into a MEM_ROOT, so the memory where ha_rocksdb objects themselves are stored are not leaked.
However, members like String ha_rocksdb::m_storage_record are not de-initialized properly, and if they had kept any pointers, we're out of luck.

There are two possible solutions:
1. Make ha_rocksdb::close() clean up all String objects (This is a hack)
2. Make ha_partition code properly delete all the objects it has allocated

The first one is easier to do but looks like a hack.

Investigating how to do the second one ...

fast_alter_partition_table() does partitioning DDL operation in several steps. Listing them in the order they are done:

mysql_change_partitions/ ha_partition::change_partitions
> here new partitions are created and saved in ha_partition::m_new_file, ha_partition::m_added_file

alter_close_table()
> here it calls ha_partition->external_lock() to remove the lock
> and also calls ha_partition->close()
> // Looks like a good place to cleanup ha_partition::m_new_file except that it's not.

mysql_rename_partitions() / ha_partition::rename_partitions()
> here it calls file->ha_delete_table() and file->ha_rename_table() for the children tables
> // This is why we could not remove them on the previous step.

Looking at the above, I dont see where exactly ha_partition should delete its newly-created child partitions. The workflow is apparently tightly coupled with the SQL layer.
Should we add handler::partitioning_ddl_done() call and have SQL layer call it, and ha_partition use this method?

(serg Any thoughts?)

Could you do it from ha_partition::close() or from ha_partition::~ha_partition()? Both are called (in that order) after mysql_rename_partitions() at the end of fast_alter_partition_table().

serg, thanks for the reply!

> Could you do it from ha_partition::close()

Cannot do that from there, as I wrote above, alter_close_table() calls ha_partition->close(), and then ha_partition::rename_partitions() requires that newly created ha_xxx ojbects are still present.

> or from ha_partition::~ha_partition()?

This one seems to work, created a patch with this, now testing in buildbot.

> Both are called (in that order) after mysql_rename_partitions() at the end of fast_alter_partition_table().

http://buildbot.askmonty.org/buildbot/grid?category=main&branch=bb-10.2-mdev13153

upstream MyRocks is not affected by this issue for some reason.