When shutting down the system, all of the ha_rocksdb internal data structures are cleaned up before deleting/deconstructing the rocksdb handle. However, now that ha_rocksdb registers with rocksdb for TableProperties callback, rocksdb's background threads running compaction are calling into ha_rocksdb to access the internal data structures.
Flipping the order of clean up (close rocksdb, then clean up internal structures) causes other problems since the internal structures are often dependent on the column family handles, whose cleanup requires the rdb to be alive.
One solution would be to close all of the column family handles while keeping the internal data structures alive and hope the compaction callbacks don't require accessing the column family handles. Another would be to have rocksdb partially shtudown by terminating all background threads before ha_rocksdb attempts to clean up its internal data structures.
When shutting down the system, all of the ha_rocksdb internal data structures are cleaned up before deleting/deconstructing the rocksdb handle. However, now that ha_rocksdb registers with rocksdb for TableProperties callback, rocksdb's background threads running compaction are calling into ha_rocksdb to access the internal data structures.
Flipping the order of clean up (close rocksdb, then clean up internal structures) causes other problems since the internal structures are often dependent on the column family handles, whose cleanup requires the rdb to be alive.
One solution would be to close all of the column family handles while keeping the internal data structures alive and hope the compaction callbacks don't require accessing the column family handles. Another would be to have rocksdb partially shtudown by terminating all background threads before ha_rocksdb attempts to clean up its internal data structures.