Whenever a "session command" is executed, the response type (success or failure) is stored to know when a backend has diverged and must be discarded. Normally these are removed when the history overflows and pruning takes place. The exception to this is when a tight loop of COM_STMT_PREPARE and COM_STMT_CLOSE is done: the history is pre-emptively pruned when the COM_STMT_CLOSE arrives to remove the COM_STMT_PREPARE for the about-to-be-closed statement from the history. This way the history remains a complete set of commands that can be executed as a batch.

The problem arises from the fact that the history responsese are only pruned when the history overflows. With the COM_STMT_PREPARE -> COM_STMT_CLOSE loop, the normal pruning never takes place and the history responses keep on being stored. This can be verified by memory usage profiling and by looking up whether MariaDBClientConnection::finish_recording_history() shows up as one of the top functions.

The solution to this is to also erase the history response whenever the history is modified.