Linux

In error.mysql.log I see that this thread is holding the InnoDB dict_operation_lock:

MySQL thread id 797, OS thread handle 140330676606720, query id 153886 localhost root

truncate table target

This might be related to the race condition that I identified in MDEV-18836.

philip_38, does this always occur when you use TRUNCATE TABLE?
It would be useful if you could obtain stack traces for all threads, with something like this:

gdb -ex 'set height 0' -ex 'thread apply all backtrace' -ex detach -ex quit -p $(pgrep -x myqsld)

philip_38, is this issue repeatable with MariaDB 10.4.3?

RocksDB is flawed in a worse way than InnoDB. While it stores the information in a fraction of the space, it manages the memory wrong, or it does not manage the memory at all.
Supposed you have a very large table with 2 BN numbers and. You start downloading data with
mysql -q -E "select * from table where number like '2%' " > 2.csv
mysql -q -E "select * from table where number like '3%' " > 3.csv
and so on, til 9
Mariadb starts growing the memory in use until Linux kills the process. It never stops growing until it crashes the box. And I am using mysql -q, which send the info out as soon as possible, so that is not the issue.
The box has already 300 GB of RAM. I am afraid it will devour all the memory available no matter how many GB I can buy.
Any idea how to get around this? InnoDB at least can load and lock the memory when using large pages. With RocksDB I have no idea how to force it to behave.

In my opinion, the memory leak is happening on any query with 'like' operator. It seems to work fine with any other type of select I have tested.

philip_38, if you have an issue with MyRocks, I would suggest that you open a separate report for that. One way to trace memory allocation would be to use tcmalloc (possibly via LD_PRELOAD) and enable the heap profiler, then analyze the output. I did that in the past to diagnose some workload with InnoDB, and visualized the logs with something that generated input for GraphViz.

Does the originally reported InnoDB problem with TRUNCATE TABLE still occur for you with MariaDB 10.4.4 or later?

I am closing this, because I am unable to analyze or repeat this based on the available amount of information.

Some InnoDB bugs were present in the release 10.4.2 and fixed later, so it is possible that this bug has already been fixed.